Re: Advance notice that I'd like to make Cabal depend on parsec

On Fri, 2013-03-15 at 10:10 +0100, Herbert Valerio Riedel wrote:

Duncan Coutts writes:

[...]

...

I've been doing regression testing against hackage and I'm satisfied that the new parser matches close enough. I've uncovered all kinds of horrors with .cabal files in the wild relying on quirks of the old parser. I've made adjustments for most of them but I will be breaking a half dozen old packages (most of those don't actually build correctly because though their syntax errors are not picked up by the parser, they do cause failure eventually).

btw, why not just keep the current parser as a "legacy" parser in the code, for older .cabal files (or as a fallback parser, in case the new stricter parsec-parser fails)?

I'm satisfied at this point that the number of packages affected by the change is so low that it's not worth the extra maintenance. As I mentioned, most of the ones that break in the new parser are actually already broken in the sense that they will not build (because of mistakes in the .cabal file that just happen not to be caught by the old parser). So the amount of "real" breakage is trivial. Also, with the new hackage server we will be able to fix .cabal files post-release so if we do care about those few older packages we can actually fix them. Duncan