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