showGenericPackageDescription leaves out many fields of executable stanza

[mgsloan]

See commercialhaskell/stack#3549 , user reports everything but main-is is vanishing from the executable stanza.

Here is cabal-roundrip-bug.hs, it can be run with stack runghc --resolver nightly-2017-11-04 cabal-roundtrip-bug.hs, and that uses Cabal-2.0.0.2.

import Distribution.PackageDescription
import Distribution.PackageDescription.Parse
import Distribution.PackageDescription.PrettyPrint

main = do
  let input = unlines
        [ "name: bug"
        , "version: 1"
        , "build-type: Simple"
        , "cabal-version: >= 1.2"
        , ""
        , "executable bug"
        , "  default-language: Haskell2010"
        ]
      ParseOk _ parsedInput = parseGenericPackageDescription input
  let rendered = showGenericPackageDescription parsedInput
      ParseOk _ roundtripped = parseGenericPackageDescription rendered
  if parsedInput == roundtripped
    then putStrLn "Success!"
    else error $ unlines
      [ "Mismatch after roundtripping cabal file through render + parse."
      , ""
      , "-- Input was:"
      , ""
      , input
      , ""
      , "-- Input parsed and rendered is:"
      , ""
      , rendered
      ]

Result is

cabal-roundtrip-bug.hs: Mismatch after roundtripping cabal file through render + parse.

-- Input was:

name: bug
version: 1
build-type: Simple
cabal-version: >= 1.2

executable bug
  default-language: Haskell2010


-- Input parsed and rendered is:

name: bug
version: 1
cabal-version: >=1.2
build-type: Simple
license: UnspecifiedLicense

executable  bug



CallStack (from HasCallStack):
  error, called at cabal-roundtrip-bug.hs:20:10 in main:Main

[phadej]

Duplicate of #4719, already fixed in master by #4702

[mgsloan]

Gotcha, thanks. I was searching for showGenericPackageDescription not writeGenericPackageDescription so didn't find that.

Would you mind if we shipped master version of Cabal with stack-1.6? Is there anything WIP there that would affect package parsing? ( Would still use release version of Cabal for building)

[phadej]

Well, then you cannot really release that version of stack to Hackage.

But if you are willing to support both released Cabal, and some single commit in HEAD (via special stack.yaml), why not. Another solution is to vendor in the relevant part of Cabal (which is unfortunately: almost everything except Distribution.Simple).

Any way of pick, you have to make sure to reject cabal-version: 2.1 and later, as their spec is open atm.

[mgsloan]

True, this will be broken in stack built from Hackage. Building stack from hackage is not a supported / reocmmended approach, though people still do it on occasion. We much prefer the binary distributions or built via stack, because then we can be sure behavior variation isn't because they happened to pick different dependencies.

And yep, stack uses full PVP bounds https://hackage.haskell.org/package/stack-1.5.1/stack.cabal

[phadej]

By

Any way of pick, you have to make sure to reject cabal-version: 2.1 and later, as their spec is open atm.

I meant you should reject .cabal files with too new Cabal spec version, there are features in master which may not be in their final form.

[mgsloan]

Ah that makes sense, thanks for the clarification. Didn't read that bit very carefully. I've opened an issue to discuss whether this should be done before the release.

[hvr]

and some single commit in HEAD (via special stack.yaml), why not.

I would add a big disclaimer here; if you rely on HEAD you're totally on your own; there are no support guarantees whatsoever. We're in the midst of migrating to a totally new parsec parser, and there's a good chance some stuff may not work properly yet; so in the interest of forward/backward compat you seem to value so much, I'd rather discourage relying on HEAD for a mission critical product.

Building stack from hackage is not a supported

If that's really the case, I'd politely ask you to refrain from uploading to Hackage at all, as Hackage is primarily intended for packages which you expect and support users to install from there via cabal. It's not meant to be abused as a cheap storage or backup service.

[mgsloan]

We're in the midst of migrating to a totally new parsec parser, and there's a good chance some stuff may not work properly yet; so in the interest of forward/backward compat you seem to value so much, I'd rather discourage relying on HEAD for a mission critical product.

Thanks for the heads up. Yes, preserving forwards and backwards compatibility when possible is certainly something that I prefer to preserve....

Perhaps it will be sufficient to backport the fix, or perhaps the fix occurred before any major changes?

If that's really the case, I'd politely ask you to refrain from uploading to Hackage at all, as Hackage is primarily intended for packages which you expect and support users to install from there via cabal

I suppose equality constraints could enable the correct versions to be used by cabal-install. However, it is sometimes useful to use stack as a library, particularly in scripts - commercialhaskell/stack#3522 . To allow this use-case, the version constraints need to be intervals, not equalities.

There is an alternative option, though, which would be to have the executable use equality constraints for all of the dependencies (including those of the library). Supporting this would likely mean adding a manual flag which disables building the executable..

[hvr]

There's an even better way by using automatic flags like I did e.g. in http://hackage.haskell.org/package/cabal-plan-0.2.0.0/cabal-plan.cabal

[dan-t]

Is there a release date for Cabal 2.1 or for a Cabal 2.0.x with a fixed showGenericPackageDescription?

The broken showGenericPackageDescription is currently a show stopper for me updating to Cabal 2.0.

Thanks for any hints!

[23Skidoo]

Cabal 2.2 will be out ~at the end of January. See https://mail.haskell.org/pipermail/cabal-devel/2017-December/010410.html.