In message <200804180805.12793.jgoerzen@complete.org> John Goerzen
On Fri April 18 2008 4:43:24 am Duncan Coutts wrote:
It seems arbitrary that Hackage would suddenly reject this valid usage.
Yes it is valid though I hope you can see the general intention of the suggestion. If it were not for the compatibility problem it would be preferable to use:
Sure, I do. It's a good point.
But I think there are a couple of issues here:
1) Hackage is rejecting things that Cabal accepts without trouble
This is by design. There are dubious things you can do locally that are not really acceptable in publicly distributed packages. As a simple example you can't put 'AllRightsReserved' packages on the public hackage. Hackage upload is an excellent point to apply stricter QA for distributed packages than what you'd use locally for quick hacks. Remember that Cabal is aimed as a haskell build system as well as a haskell package distribution system. So it does not make sense in every context to apply the strictest levels of checking. For example in the longer term I'd like to see 'cabal build Foo.hs' as an upgraded 'ghc --make Foo.hs' ie just the ordinary build stuff - but with parallel build and understanding preprocessors and without having to supply a .cabal file. So the Cabal checking code has a few levels of severity and depending on the context we make those fatal errors, warnings or ignore them completely. The strictest levels of checks are reserved for distributing packages. It's easy to adjust the levels for individual checks.
2) The behavior of Hackage is unpredictable in what it will accept and what it will reject
Actually with the latest Cabal it's quite predictable. 'cabal sdist' now reports exactly the same errors and warnings as hackage upload. You see the difference at the moment because you're using an older version of Cabal compared to the one on hackage. There is also a new 'cabal check' command for running these additional QA checks (which we hope to extend with more expensive checks along the lines of autotools's 'make distcheck' feature).
3) The behavior of Hackage changes rapidly
They will remain synchronised because Hackage just uses the Cabal library to do its checks. It changed very rapidly recently because we added this checking infrastructure and added dozens of new checks based on looking at the dubious things people have put in existing .cabal files in hackage packages.
It's been quite frustrating lately as many of my packages that used to upload fine still build fine but get rejected at upload time.
If there are any that you think are rejecting legitimate packages then do complain (as in this thread). They're not set in stone. Probably better to complain to cabal-devel or the libraries list, or file bug repots so we spot them. I do realise there is the danger of going too far and having pointless finicky rules. We rely on feedback on this.
I think that Hackage is the wrong place for these checks.
I disagree. I think it's absolutely the best place for these checks. Of course they need to be in the client too, that's coming soon with Cabal-1.4 (or now if you use the development version of Cabal). As an ex-linux-distro maintainer I think this is absolutely the right thing to do - to automate and distribute QA as much as possible. Maintaining and improving the quality of the hackage collection is really important.
This stuff should go in Cabal, and ./setup configure should print a big DEPRECATION WARNING for a major release before the stuff gets yanked.
Yes, that's what will happen when you use the new Cabal (the same version that hackage is using). Though it will not print all warnings on configure because we think that'd probably be too annoying for people working on quick hacks. But it does run the full set of checks with the 'check' and 'sdist' commands.
So that obviously does not solve the problem that Cabal-1.2 and older are not very good with forwards compat in the parser. The solution is probably just to downgrade that check to a warning rather than outright rejection (or possibly limit the check to extensions that existed in older Cabal versions). We can make it stricter again in the future when Cabal-1.4+ is much more widely deployed.
Sound ok?
Yes, that makes a lot of sense, too. Can cabal-put be tweaked to make sure to output that warning by default?
There's a bug open on that and Ross and Bjorn are working on getting the cgi upload script to reporte errors/warnings to http clients that only accept text not html output (ie cabal upload). Does that help explain what's going on and what we're up to with this checking stuff? I should also note that there will be a Cabal-1.4 and cabal-install release in the near future but you can grab the pre-releases or the darcs versions now and try things out and report any problems. The first pre-release was announced to the libraries list a bit over a week ago. I'll probably announce the next pre-release on this list so we get wider testing. Duncan