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

[Duncan Coutts]

On Fri, 2013-03-15 at 10:10 +0100, Herbert Valerio Riedel wrote:
> Duncan Coutts <duncan.coutts at googlemail.com> 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