Should one reject to work with such files, or should we be optimistic and try anyway (yet report the version error, not the parse error?)
I can amend ParseResult to also return the cabal-version, even the parse fails, so users of parseGenericPackageDescription can either fail or skip.
-newtype ParseResult = ParseResult (Writer (warnings, errors) (Maybe a))
+newtype ParseResult = ParseResult (Writer (warnings, errors, cabalVersion) (Maybe a))
I can amend
ParseResultto also return thecabal-version, even the parse fails,
+1, that would be useful.
Yes, I think the general idea is that the format of the header, or at least the format far enough to read cabal-version, must stay stable enough so that old versions of Cabal can parse far enough to determine that they don't support a version. In practice I don't think old version of Cabal's actually fulfill this property... but never too early to start right?
@ezyang I've put quite a bit of thought into the cabal-spec forward/backware compat story, but I don't have time to explain it right now (I hint at this here); but my plan allows us to radically change the lexical structure of .cabal files w/o breaking old cabal-installs :-)
@hvr's plan is now described in #4899.
This is done
Most helpful comment
I can amend
ParseResultto also return thecabal-version, even the parse fails, so users ofparseGenericPackageDescriptioncan either fail or skip.