yes, that sounds promising. but then i recalled my standard answer when microsoft asks me to let them know the details about how acrobat plugin or ghc or whatever have crashed: it is "no", plain and simple. so, perhaps promising in theory, but not in practice?
Privacy is obviously of vital importance as I noted.
it isn't so much reasonable privacy concerns, but unreasonable aversion. also, it is easier to say "no" than to check a large dump of data for privacy issues;-) but, as Ian says, try it and see what happens.
note also that i was talking about .cabal files *specifying* platform-dependencies, and hackage verifying them, not about hackage inferring platform-dependencies from build/failure-reports!-)
Well, you might have access to Windows, Mac, Linux and Solaris boxes but I certainly do not. Most other package developers do not either. So they cannot specify anything except by feedback from people who do have access to those platforms.
ah, neither do i. but i have worked on versions of unix and i have worked on windows. the kind of platform dependency that bugs me is the *unnecessary* one, where people use platform-specific tricks and tools because they don't know better. then you can't use some wonderful library W because you're not on windows, and W uses a windows-specific dependency instead of a portable one. or you can't use another wonderful library U because it uses a unix- specific dependency instead of a portable one, and you happen to be on windows. and then you find that you can't build your wonderful application idea, because the libraries W and U exist that would do the job, but there is no platform on which both work.. there isn't much anyone can do about the *necessary* platform dependencies, as someone just has to do the porting work. but for *unnecessary* platform specifics, the way to get a portable version is by removing them. and to do that, you have to know whether something that works perfectly on your system is or is not in that subset that will work on many platforms without porting. and the easiest way to do that if you have to specify all your dependencies anyway, as in cabal, is if those dependencies declare their status wrt portability, and portability gets propagated to dependent packages. if choosing unix-compat over unix makes the difference between cabal-check accepting my .cabal file as portable or limited to unix, i will be more likely to use unix-compat when i can. same for opengl vs some windows-specific 3d graphics, etc. etc. if someone insists on mis-managing path separators for themselves instead of using a portable package for that, there is nothing cabal can do about it. that is when your hackage feedback comes in. what i'm concerned about are all those simpler cases that cabal could handle and that would make life so much easier.. :-) Ian asks: |What would go in README that wouldn't go in either |the Cabal "description" field or the haddock docs? ideally, anything that can be checked should be in formal fields, such as build-tools, etc. until recently, many of those fields didn't even exist, and they aren't widely used yet. a description is an informal field, but i'd be tempted to keep it brief and to the point. the README file is the one i go for to figure out that this is a cabal-32.4,5 package, what that means, and what the how-to-build instructions of the day are for this kind of package. other than that, the README file can cover all those things that do not yet have working .cabal fields, but over time, more and more information will move to .cabal (project url, project mailing list, bug tracker, darcs repo, haddocks, build process, do we need mingw/autotools or what, has the maintainer retired, where to send donations, etc..;-) i'm willing to think of some future .cabal file versioin as a formalised README, but if i see that version of cabal for the first time, i still need some kind of friendly welcome. and until .cabal files do capture everything, the frequent lack of README files is just frustrating (recall a thread a while ago where someone was trying to figure out the various database bindings?).
Yes, when we thought about this before we all agreed it'd be a nice thing. It'd be even nicer if someone had the time to implement it.
Hackage already does some additional checks but letting developers run those checks on their own machines and extending the set of checks would be great.
Would you like to start by filing your list of suggested checks in a trac feature request?
my interest are wide-ranging, but my capacities are limited!-) currently, cabal is just outside that limit. i occasionally browse this group via gmane, and i try to direct any cabal-related suggestions here, but that's about it for now, i'm afraid. please feel free to record any suggestions you like on your tracker, for later use by future volunteers. hope that doesn't make my occasional suggestions unwelcome, claus
I think this kind of non-core feature would be better to go in the cabal-install tool, though obviously using the Cabal library api.
Duncan