portability and .cabal files?
how is portability (meant to be) documented in .cabal files? the only thing i can find in Cabal/authors.html are 'os()' and 'arch()', but those are tests, rather than dependency fields. should .cabal files for non-portable packages consist of a big if with the tested and known-to-work os/arch combinations as test and an empty else-branch for unknown/untested/known-to-fail combinations? shouldn't hackage display portability of its packages? if i look through the system-dependent packages on hackage, hardly any of them indicate their platform limitations anywhere but in free-form comments and module names, so if you wanted to filter packages by supported platforms, you'd be stuck.. claus
On Fri, Nov 23, 2007 at 01:05:42AM -0000, Claus Reinke wrote:
how is portability (meant to be) documented in .cabal files? the only thing i can find in Cabal/authors.html are 'os()' and 'arch()', but those are tests, rather than dependency fields.
should .cabal files for non-portable packages consist of a big if with the tested and known-to-work os/arch combinations as test and an empty else-branch for unknown/untested/known-to-fail combinations?
shouldn't hackage display portability of its packages?
if i look through the system-dependent packages on hackage, hardly any of them indicate their platform limitations anywhere but in free-form comments and module names, so if you wanted to filter packages by supported platforms, you'd be stuck..
Hackage ought to show impl, os and arch tests, but it doesn't yet. One possibility is to put them in the dependency lists, e.g. os(windows), base, Win32 OR !os(windows), base, X11 I guess you could indicate that a package won't build in some configuration using the buildable field. Hackage ought to learn to use that too.
On Fri, 2007-11-23 at 01:42 +0000, Ross Paterson wrote:
I guess you could indicate that a package won't build in some configuration using the buildable field. Hackage ought to learn to use that too.
Oh you mean we should say: if os(windows) -- this package is known not to work on windows buildable: false and then cabal should fail on configuration, and cabal-install should not consider depending on that package in that configuration? Duncan
On Fri, Nov 23, 2007 at 02:34:43AM +0000, Duncan Coutts wrote:
On Fri, 2007-11-23 at 01:42 +0000, Ross Paterson wrote:
I guess you could indicate that a package won't build in some configuration using the buildable field. Hackage ought to learn to use that too.
Oh you mean we should say:
if os(windows) -- this package is known not to work on windows buildable: false
and then cabal should fail on configuration, and cabal-install should not consider depending on that package in that configuration?
It's not ideal, because buildable is a per-component thing, but I think Cabal already fails if none of the components is buildable.
On Fri, 2007-11-23 at 09:22 +0000, Ross Paterson wrote:
On Fri, Nov 23, 2007 at 02:34:43AM +0000, Duncan Coutts wrote:
On Fri, 2007-11-23 at 01:42 +0000, Ross Paterson wrote:
I guess you could indicate that a package won't build in some configuration using the buildable field. Hackage ought to learn to use that too.
Oh you mean we should say:
if os(windows) -- this package is known not to work on windows buildable: false
and then cabal should fail on configuration, and cabal-install should not consider depending on that package in that configuration?
It's not ideal, because buildable is a per-component thing, but I think Cabal already fails if none of the components is buildable.
Well, for dependencies we only consider the library component anyways. I don't think we currently have a way to specify dependencies on an executable provided by a Cabal package.
I guess you could indicate that a package won't build in some configuration using the buildable field. Hackage ought to learn to use that too.
Oh you mean we should say:
if os(windows) -- this package is known not to work on windows buildable: false
and then cabal should fail on configuration, and cabal-install should not consider depending on that package in that configuration?
if hackage started to display platform dependencies, that might help to get .cabal authors to document them. but there would need to be a single convention for documenting this, and it would have to be advertized and promoted, perhaps even enforced. having lots of packages is no good unless they work on your platform, and being explicit about which platforms a package does not (currently, for lack of porting, or ever, for hardwired dependencies) work is the first step toward improving the situation. i'd much rather have hackage tell me which packages are usable with my platform (build-reports verifying .cabal file accuracy), than tell me how many people on other platforms are using those packages without caring about portability to other platforms!-) claus
On Sun, 2007-11-25 at 18:07 +0000, Claus Reinke wrote:
having lots of packages is no good unless they work on your platform, and being explicit about which platforms a package does not (currently, for lack of porting, or ever, for hardwired dependencies) work is the first step toward improving the situation.
Yes.
i'd much rather have hackage tell me which packages are usable with my platform (build-reports verifying .cabal file accuracy), than tell me how many people on other platforms are using those packages without caring about portability to other platforms!-)
Absolutely, I'd like to see this too. My proposal is along those lines, that we use cabal-install to gather test feedback and that hackage should collect and summarise that data. It's not trivial however, it needs quite a lot of infrastructure. I opened a bug on it the other day: http://hackage.haskell.org/trac/hackage/ticket/184 Duncan
i'd much rather have hackage tell me which packages are usable with my platform (build-reports verifying .cabal file accuracy), than tell me how many people on other platforms are using those packages without caring about portability to other platforms!-)
Absolutely, I'd like to see this too. My proposal is along those lines, that we use cabal-install to gather test feedback and that hackage should collect and summarise that data. It's not trivial however, it needs quite a lot of infrastructure.
I opened a bug on it the other day:
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? 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!-) btw, i haven't followed developments closely but, at various points in the past, we have talked about a 'runhaskell Setup check' that would help to check conformance to some minimal guidelines before publishing a cabal package, such as: - is there a README file? this should be a must, and there are too many packages on hackage that hardly tell me anything about what they do, nor how or whether they build on my platform (the how has been improving with new .cabal fields, but those fields aren't used everywhere..) - is there a build-tools field? if there is no README, this is a must have. - are platform dependencies specified? here cabal would need to prescribe a standard way to specify these in the .cabal file - are there no open-ended dependency versions? (cf package versioning discussion) - etc. if there was a 'check' command, writing the documentation for it would clarify many of the currently implicit conventions of writing .cabal files. and if running 'check' would be a pre-requisite for publishing on hackage, more packages would make good use of those conventions. just another suggestion for the haskell cabal folks!-) claus
On Tue, Nov 27, 2007 at 12:32:45AM -0000, Claus Reinke wrote:
i'd much rather have hackage tell me which packages are usable with my platform (build-reports verifying .cabal file accuracy), than tell me how many people on other platforms are using those packages without caring about portability to other platforms!-)
Absolutely, I'd like to see this too. My proposal is along those lines, that we use cabal-install to gather test feedback and that hackage should collect and summarise that data. It's not trivial however, it needs quite a lot of infrastructure.
I opened a bug on it the other day:
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?
I don't know how hackage would fair, but we get a number of Debian users giving feedback via the popularity-contest package: http://people.debian.org/~igloo/popcon-graphs/index.php?packages=ghc6,hugs&show_installed=on&want_legend=on&want_ticks=on&from_date=&to_date=&hlght_date=&date_fmt=%25Y-%25m&beenhere=1 All we can do is try it and see what happens, I think.
- is there a README file? this should be a must, and there are too many packages on hackage that hardly tell me anything about what they do, nor how or whether they build on my platform (the how has been improving with new .cabal fields, but those fields aren't used everywhere..)
What would go in README that wouldn't go in either the Cabal "description" field or the haddock docs?
- is there a build-tools field? if there is no README, this is a must have.
Once Cabal uses the build-tools field in the same way that it uses the build-depends field you won't be able to omit this (unless you don't need any tools to build). Thanks Ian
On Tue, 2007-11-27 at 00:32 +0000, Claus Reinke wrote:
I opened a bug on it the other day:
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.
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. (As it happens I'm pretty lucky and do have access to Linux and logins to Solaris and Windows servers. But Macs are pretty expensive and the department don't have any Mac servers.)
btw, i haven't followed developments closely but, at various points in the past, we have talked about a 'runhaskell Setup check' that would help to check conformance to some minimal guidelines before publishing a cabal package, such as:
- is there a README file? this should be a must, and there are too many packages on hackage that hardly tell me anything about what they do, nor how or whether they build on my platform (the how has been improving with new .cabal fields, but those fields aren't used everywhere..)
- is there a build-tools field? if there is no README, this is a must have.
- are platform dependencies specified? here cabal would need to prescribe a standard way to specify these in the .cabal file
- are there no open-ended dependency versions? (cf package versioning discussion)
- etc.
if there was a 'check' command, writing the documentation for it would clarify many of the currently implicit conventions of writing .cabal files. and if running 'check' would be a pre-requisite for publishing on hackage, more packages would make good use of those conventions.
just another suggestion for the haskell cabal folks!-)
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? 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
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
participants (5)
-
Claus Reinke -
Duncan Coutts -
Ian Lynagh -
Ross Paterson -
Thomas Schilling