[Haskell-cafe] Hackage being too strict?

[Duncan Coutts]

On Tue, 2008-04-15 at 22:15 -0500, John Goerzen wrote:
> When I went to make my upload of MissingH 1.0.1, Hackage rejected it,
> saying:
> 
> Instead of 'ghc-options: -XPatternSignatures' use 'extensions: PatternSignatures'
> 
> It hadn't rejected MissingH 1.0.0, even though it had the same thing.

I added loads of extra checks recently.

> Now, my .cabal file has this:
> 
>  -- Hack because ghc-6.6 and the Cabal the comes with ghc-6.8.1
>  -- does not understand the PatternSignatures extension.
>  -- The Cabal that comes with ghc-6.8.2 does understand it, so
>  -- this hack can be dropped if we require Cabal-Version: >=1.2.3
>  If impl(ghc >= 6.8)
>    GHC-Options: -XPatternSignatures
> 
> which was contributed by Duncan Coutts.

:-)

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

iIf impl(ghc >= 6.8)
   extensions: PatternSignatures

or just unconditionally if that makes sense:

extensions: PatternSignatures

because it encourages packages to declare what the need in a way that is
not compiler-specific (which was one of the aims of Cabal in the first
place).

> Thoughts?

Mmm. So the problem is that previously the .cabal parser was pretty
unhelpful when it came to forwards compatibility. For example for the
Extension enumeration type it was just using the Read instance which
meant that it would fail with a parse error for any new extensions.
That's the real source of the problem, that the parser allows no
forwards compatibility so when new extensions are added, older Cabal
versions will fail with a parse error.

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,
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.

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?

Duncan