[Haskell-cafe] Hackage being too strict?

[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

2) The behavior of Hackage is unpredictable in what it will accept and what 
it will reject

3) The behavior of Hackage changes rapidly

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.

I think that Hackage is the wrong place for these checks.  This stuff should 
go in Cabal, and ./setup configure should print a big DEPRECATION WARNING 
for a major release before the stuff gets yanked.

> I have now fixed that by eliminating the use of Read in the .cabal
> parser and basically adding an Other/Unknown constructor to several of
> the enumeration types, including Extension. So as of Cabal-1.4 it will
> be possible to add new extensions in later Cabal versions that are not
> in Cabal-1.4 without Cabal-1.4 falling over with a parse error. Indeed,

That's great news.

> if the compiler knows about the extension then it will actually work.
> The only restriction is that unknown extensions cannot be used in
> packages uploaded to hackage, which is pretty reasonable I think. If an
> extension is going to be used in widely distributed packages then that
> extension should be registered in Language.Haskell.Extension. It's
> trivial to add and update hackage to recognise it.

That makes sense.

> 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?

-- John