can I indicate that an old version is not to be used, and some more questions
I uploaded a version of the uu-parsinglib to hackage. Only later I discovered that it depended on a verion of base >= 4.2, whereas I indicate > 4 in my .cabal file. I repaired this by uploading a new version in which only the cabal file has changed. This raises the following questions: - the Haskell code did not change, but I still had to bump the version number? - can I remove the incorrect version or indicate that it is superseded by the new version? - since I do not have a wide variety of Haskell installations and package versions on my machine, it would be very nice if the hackage server could test a package against the extremes of the indicated dependency ranges before installing. This would have prevented the mistake I made (and which undoubtedly others will make too) Doaitse
On Fri, 23 Jul 2010, S. Doaitse Swierstra wrote:
I uploaded a version of the uu-parsinglib to hackage. Only later I discovered that it depended on a verion of base >= 4.2, whereas I indicate > 4 in my .cabal file.
I repaired this by uploading a new version in which only the cabal file has changed. This raises the following questions:
- the Haskell code did not change, but I still had to bump the version number?
If you follow the Package Version Policy then increasing the version number from 2.4.1 to 2.4.1.1 would be the right thing to do.
- can I remove the incorrect version or indicate that it is superseded by the new version?
A new version is automatically preferred on installation and thus somehow hides older versions.
- since I do not have a wide variety of Haskell installations and package versions on my machine, it would be very nice if the hackage server could test a package against the extremes of the indicated dependency ranges before installing. This would have prevented the mistake I made (and which undoubtedly others will make too)
Sure, tool support for dependency checking is highly wanted, but still does not exist.
S. Doaitse Swierstra wrote:
I uploaded a version of the uu-parsinglib to hackage. Only later I discovered that it depended on a verion of base >= 4.2, whereas I indicate > 4 in my .cabal file.
I repaired this by uploading a new version in which only the cabal file has changed. This raises the following questions:
- the Haskell code did not change, but I still had to bump the version number?
The package as a whole has changed. I think that requiring a version number bump is the right thing to do, otherwise there is no certainty about what precisely a given version of a package actually is.
- can I remove the incorrect version or indicate that it is superseded by the new version?
Isn't that implicit in having a bumped version number?
- since I do not have a wide variety of Haskell installations and package versions on my machine, it would be very nice if the hackage server could test a package against the extremes of the indicated dependency ranges before installing. This would have prevented the mistake I made (and which undoubtedly others will make too)
There's work going on in this area with the hackage 2 server, but I think it'll mostly come in the form of getting build reports after a package has been published, rather than having them rejected before publication. The more work the hackage server itself is expected to do, the harder it will be to maintain, so the proposed architecture is for other people to be able to submit build reports. Ganesh =============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ===============================================================================
On Fri, 23 Jul 2010, Sittampalam, Ganesh wrote:
There's work going on in this area with the hackage 2 server, but I think it'll mostly come in the form of getting build reports after a package has been published, rather than having them rejected before publication. The more work the hackage server itself is expected to do, the harder it will be to maintain, so the proposed architecture is for other people to be able to submit build reports.
For me the best solution would neither be letting Hackage reject packages automatically, nor waiting for build report of others, but being able to run a dependency checker on my machine before uploading. Even today I use a script that tries to compile the package from the tarball before uploading. This way I can quickly spot files, that I forgot to include in the Cabal file. No need to wait for Hackage or other users. It would be nice to have this for version consistency, too.
I of course test things on my machine before uploading; it is only that I do not have several Haskell compilers installed, nor all versions of package base, etc. Having this at a single location would make life easier and cabal files more reliable. I can test the code on my machine, but not the installation process in other environments. Doaitse On 23 jul 2010, at 11:13, Henning Thielemann wrote:
On Fri, 23 Jul 2010, Sittampalam, Ganesh wrote:
There's work going on in this area with the hackage 2 server, but I think it'll mostly come in the form of getting build reports after a package has been published, rather than having them rejected before publication. The more work the hackage server itself is expected to do, the harder it will be to maintain, so the proposed architecture is for other people to be able to submit build reports.
For me the best solution would neither be letting Hackage reject packages automatically, nor waiting for build report of others, but being able to run a dependency checker on my machine before uploading. Even today I use a script that tries to compile the package from the tarball before uploading. This way I can quickly spot files, that I forgot to include in the Cabal file. No need to wait for Hackage or other users. It would be nice to have this for version consistency, too. _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
"S. Doaitse Swierstra"
I of course test things on my machine before uploading; it is only that I do not have several Haskell compilers installed, nor all versions of package base, etc. Having this at a single location would make life easier and cabal files more reliable. I can test the code on my machine, but not the installation process in other environments.
So a stand-alone version of the buildbot used on Hackage that can be used to test packages before uploading them to Hackage? -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com
On Fri, 2010-07-23 at 10:39 +0200, S. Doaitse Swierstra wrote:
I uploaded a version of the uu-parsinglib to hackage. Only later I discovered that it depended on a verion of base >= 4.2, whereas I indicate > 4 in my .cabal file.
I repaired this by uploading a new version in which only the cabal file has changed. This raises the following questions:
- the Haskell code did not change, but I still had to bump the version number? - can I remove the incorrect version or indicate that it is superseded by the new version? - since I do not have a wide variety of Haskell installations and package versions on my machine, it would be very nice if the hackage server could test a package against the extremes of the indicated dependency ranges before installing. This would have prevented the mistake I made (and which undoubtedly others will make too)
So that we do not forget I've filed a ticket for this feature request: http://hackage.haskell.org/trac/hackage/ticket/719 People are of course welcome to add comments to the ticket. Duncan
participants (5)
-
Duncan Coutts -
Henning Thielemann -
Ivan Lazar Miljenovic -
S. Doaitse Swierstra -
Sittampalam, Ganesh