Cabal library version not included in --version output

[glguy]

It would be useful if the Cabal library version number was included in the --version output. Cabal versions affect what can be put into a .cabal file. For scripting purposes it would probably be good to complement this with a flag like --numeric-version and --hpack-numeric-version (maybe --Cabal-numeric-version)

[mgsloan]

A given official stack version should always be built against the stack.yaml versions of packages. Anything else is an un-official install, and you get what you get. Therefore, for scripting purposes, bounds on --numeric-version and an assumption of monotonicity of cabal versions should be sufficient.

Also, we used to have a feature where --version would give versions of all deps when installed with cabal-install, since that installation approach has caused bugs for our users in the past. I have started a discussion on our stack-collaborators slack about what happened to that feature.

[mgsloan]

I've closed this since I don't think we need it. If you really need it for some reason, please explain why --numeric-version is insufficient, and a PR will be considered.

[glguy]

What is a "stack.yaml" version of packages? How would I look up what official version of Cabal my stack executable is using? Making this easy to discover doesn't seem controversial.

The whole value of stack for me is that it orchestrates builds with Cabal, knowing what version of Cabal is being used seems like an easy win.

[mgsloan]

Since it uses resolver lts-6.14 currently, you can look at https://www.stackage.org/lts-6.14/package/Cabal and it will tell you 6.14

Alternatively, you can use the first line from stack exec -- ghc-pkg field Cabal version

We already had this feature, but in the month that I was on vacation, or perhaps before, it got dropped, probably to avoid the Setup.hs.

Since we already have multiple straightforward ways of doing this, and used to have a 3rd, I do not feel like adding a 4th way.

[mgsloan]

That said, it is important due to the input format considerations. Having tooling determining the match up between stack version and cabal version could be cumbersome. Re-opening due to that reconsideration.

[Blaisorblade]

Also, we used to have a feature where --version would give versions of all deps when installed with cabal-install, since that installation approach has caused bugs for our users in the past. I have started a discussion on our stack-collaborators slack about what happened to that feature.

That feature was added in #2223, and then limited to cabal builds by default in d7eaa53 #2223 (comment). Note we still always use Setup.hs. The reasoning was that we stack developers don't need all that information because we can reconstruct it, so it's noise we can hide from users. Conversely, @glguy has a different use case. We can implement this feature on top of that by altering Setup.hs a bit.

From looking at the code, everything seems still in place, so I'd guess that @glguy's stack is built with stack. @glguy where's your stack from? Can you post stack --version?

---

Since you already agreed I'm not sure that's necessary to point out, but FTR I'm not sure the "straightforward" approaches mentioned actually work.

Regarding the "current" ways to get the Cabal version, the one I'm confident about is

• figure out Stack's revision (tag/commit id)
• look up stack.yaml
• figure out which Cabal version it uses, either from the resolver or from overrides in extra-deps.

As mentioned, that's good for Stack devs, I'm not sure for users.

Conversely, I'm confused why stack exec -- ghc-pkg field Cabal version would be relevant, unless you actually built your stack with the GHC in use. From a stack checkout I'd have hope, but I get

stack exec -- ghc-pkg field Cabal version
version: 1.22.8.0
version: 1.22.5.0

because GHC uses 1.22.5.0 but the snapshot (and stack) use 1.22.8.0.

[glguy]

This appears to be resolved. I notice in my current version of stack I get the following:

$ stack --version
Version 1.2.0 x86_64
Compiled with:
- Cabal-1.24.1.0
- Glob-0.7.12
- HUnit-1.3.1.2
- MonadRandom-0.4.2.3
- QuickCheck-2.9.2
...

[Blaisorblade]

@glguy Not quite: the issue is about that info not being included in all builds, and your build uses custom versions of dependencies (no release of 1.2.0 was built against Cabal-1.24.1.0)*. So reopening (unless there's independent confirmation this was fixed).

*EDIT: specifically, I checked https://github.com/commercialhaskell/stack/blob/v1.2.0/stack-8.0.yaml, which points to https://www.stackage.org/nightly-2016-07-19 and picks Cabal-1.24.0.0.