Print dependencies version in --version

[phadej]

Addresses: #2222

I have no idea how to differentiate between whether package is build with stack or cabal, and AFAICS you can screw dependencies with custom stack.yaml as well (not so easily though).

The output of --version is now quite long, but OTOH, dunno if it used much for anything else then issue reporting?

% stack exec stack -- --version
Version 1.1.3, Git revision fb3f1d23d82e633cbc8d07dcbaf1f14c8c358751 (dirty) (3700 commits) x86_64 hpack-0.14.0
Compiled with:
- Cabal-1.22.8.0
- aeson-0.11.2.0
- ansi-terminal-0.6.2.3
- async-2.1.0
- attoparsec-0.13.0.2
- base-4.8.2.0
- base-compat-0.9.1
- base16-bytestring-0.1.1.6
- base64-bytestring-1.0.0.1
- binary-0.7.5.0
- binary-tagged-0.1.4.0
- blaze-builder-0.4.0.2
- byteable-0.1.1
- bytestring-0.10.6.0
- conduit-1.2.6.6
- conduit-extra-1.1.13.1
- containers-0.5.6.2
- cryptohash-0.11.9
- cryptohash-conduit-0.1.1
- deepseq-1.4.1.1
- directory-1.2.2.0
- edit-distance-0.2.2.1
- either-4.4.1.1
- enclosed-exceptions-1.0.1.1
- errors-2.1.2
- exceptions-0.8.2.1
- extra-1.4.7
- fast-logger-2.4.6
- filelock-0.1.0.1
- filepath-1.4.0.0
- fsnotify-0.2.1
- generic-deriving-1.10.4.1
- gitrev-1.2.0
- hashable-1.2.4.0
- hastache-0.6.1
- hit-0.6.3
- hpack-0.14.0
- hpc-0.6.0.2
- http-client-0.4.28
- http-client-tls-0.2.4
- http-conduit-2.1.10.1
- http-types-0.9
- lifted-base-0.2.3.6
- microlens-0.4.4.0
- monad-control-1.0.1.0
- monad-logger-0.3.18
- monad-unlift-0.2.0
- mtl-2.2.1
- open-browser-0.2.1.0
- optparse-applicative-0.12.1.0
- optparse-simple-0.0.3
- path-0.5.7
- path-io-1.1.0
- persistent-2.2.4.1
- persistent-sqlite-2.2.1
- persistent-template-2.1.8.1
- pretty-1.1.2.0
- process-1.2.3.0
- project-template-0.2.0
- regex-applicative-text-0.1.0.1
- resourcet-1.1.7.4
- retry-0.7.2
- safe-0.3.9
- semigroups-0.18.1
- split-0.2.3.1
- stack-1.1.3
- stm-2.4.4.1
- store-0.1.0.1
- streaming-commons-0.1.15.5
- tar-0.5.0.3
- template-haskell-2.10.0.0
- temporary-1.2.0.4
- text-1.2.2.1
- text-binary-0.2.1
- time-1.5.0.1
- tls-1.3.8
- transformers-0.4.2.0
- transformers-base-0.4.4
- unix-2.7.1.0
- unix-compat-0.4.1.4
- unordered-containers-0.2.7.0
- vector-0.11.0.0
- vector-binary-instances-0.2.3.2
- yaml-0.8.17.1
- zip-archive-0.2.3.7
- zlib-0.6.1.1

[silky]

i think it'd be great to only output all those other versions with the verbose flag set: stack --version -v (edit: actually this is the suggestion in the original issue)

[phadej]

The way optparse-applcative works, we cannot make --version -v, because of how infoOption works

EDIT we could add --verbose-options or --dump-dependencies, but I'm not sure if it's ok-ish.

[phadej]

ping @mgsloan, opinions on this?

[mgsloan]

Cool, thanks for working on this @phadej

I would really rather avoid a custom Setup.hs, but since you've already written it, I'm fine with keeping it. An alternative approach might be to use TH, and parse the versions out of $DIST_DIR/package.conf.inplace. We already extract a bit of info from that file here. Not sure how to get DIST_DIR while in TH, though. Perhaps by parsing the commandline XD. If you don't want to try this approach, I will still merge the PR, and create an issue tracking this improvement.

I actually think this should be outputted at the top of every stack -v log. The purpose is to bring attention to stack being built by cabal so that we can know whether to suspect differences in dependencies causing differences in behavior.

We don't need to have this information for stack because as long as the repo isn't dirty and it's on an existing commit (better yet, stable version). All bets of reproducibility are off when you have a dirty working copy, so we don't really need the info in that case. You can detect if it's built by stack by checking for STACK_EXE within Setup.hs.

[phadej]

@mgsloan, the custom Setup.hs is courtesy of ekmett libraries, would be handy if we start to write doctests. I guess you can build non-dirty non-weird-githash stack using different stack.yaml in the repository. E.g. by having STACK_YAML exported. But I guess we could have GHC or base library exposed in --version string?

[mgsloan]

LGTM, thanks!

[mgsloan]

I've added d7eaa53 so that the default build omits this. Stable releases do not need this info.

I also opened this issue - #2450 - to track providing all transitive dependencies and possibly remove Setup.hs

[Blaisorblade]

Question: @phadej patch produces a Build_stack-test.hs starting with module Build_stack-test where, but - appears forbidden in module names (parse error below). Also, do we need that module at all?

/Users/pgiarrusso/Documents/Research/Sorgenti/stack/.stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/autogen/Build_stack-test.hs:1:19: error:
    parse error on input ‘-’
Failed, modules loaded: none.

[phadej]

Hmm, the Build_stack is needed to get dependency list. -test is unfortunate addition for tests, dunno when that component was added as Travis was green when I made the PR

[Blaisorblade]

To clarify, the code compiles but produces a dead module. I get that error if I try loading that module by hand, but right now Cabal ignores it altogether, maybe because it doesn't have a valid source name. Dropping the lines producing Build_stack-test.hs and leaving alone Build_stack.hs appears to work.
https://github.com/commercialhaskell/stack/blob/master/Setup.hs#L30-L38

I've now realized what motivated that code — that's coming from this doctests support code:
ekmett/distributive@4e78428#diff-094b3b0bf5f517cee3185746527b3dc9

That computes by hand the dependencies for the testsuite, so that it can... launch GHCi or something to run doctests.
ekmett/distributive@4e78428#diff-094b3b0bf5f517cee3185746527b3dc9

That explains a few other bits that were confusing me, down to listing testsuite dependencies for stack --version. But to be sure: I won't fault anybody even if he/she copy-pastes uses of Cabal, using that library isn't easy.

EDIT: I finally confirmed that testsuites relying on that script have names without hyphens, avoiding this bug: https://github.com/ekmett/distributive/blob/master/distributive.cabal
EDIT2: now I also found that you do mention the origin of Stack.hs, sorry for missing that.