[Haskell-cafe] Hackage being too strict?

[Duncan Coutts]

In message <200804180805.12793.jgoerzen at complete.org> John Goerzen
<jgoerzen at complete.org> writes:
> 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