stack path fails on first run

[spl]

When running stack path --local-install-root, I didn't expect it to download anything or try to set up the build, but it did and failed.

Steps to reproduce:

~ $ rm -rf ~/.stack
~ $ stack --version
Version 1.1.2, Git revision cebe10e845fed4420b6224d97dcabf20477bbd4b (3646 commits) x86_64 hpack-0.14.0
~ $ mkdir tmp && cd tmp
~/tmp $ echo "resolver: lts-5.16" > stack.yaml
~/tmp $ stack path --local-install-root

Expected:

~/tmp/.stack-work/install/x86_64-linux/lts-5.16/7.10.3
~/tmp $ echo $?
0

Actual:

Downloaded lts-5.16 build plan.
remote: Counting objects: 219532, done.
remote: Compressing objects: 100% (176963/176963), done.
remote: Total 219532 (delta 58633), reused 173053 (delta 40353), pack-reused 0
Receiving objects: 100% (219532/219532), 51.44 MiB | 18.83 MiB/s, done.
Resolving deltas: 100% (58633/58633), completed with 1 local objects.
From github.com:commercialhaskell/all-cabal-hashes
 * [new tag]         current-hackage -> current-hackage
Fetched package index.
Populated index cache.
Compiler version mismatched, found ghc-7.6.3 (x86_64), but expected minor version match with ghc-7.10.3 (x86_64) (based on resolver setting in /home/ubuntu/blah/stack.yaml).
Try running "stack setup" to install the correct GHC into /home/ubuntu/.stack/programs/x86_64-linux/
~/tmp $ echo $?
1

Discussion:

I'd like to use stack path --local-install-root in a Makefile to determine a path like so:

INSTALL_DIR := $(shell stack path --local-install-root)

But (GNU) make runs the $(shell ...) function on load so the above failure is happening even before running any targets in the Makefile.

Questions:

1. Should stack path do the above things and fail?
2. Is there another way to generate the path with stack?

Workarounds:

I do run stack setup later in the Makefile. I could possibly run it earlier than stack path; however, part of the reason for the existence of the Makefile is to do the setup as well as to avoid it if I don't need it for a particular target. In order to do that, I need the path.

I could, of course, define $(INSTALL_DIR) based on the known parts (.stack-work/install, x86_64-linux, lts-5.16, 7.10.3), but this opens me up to breakage if stack ever changes to use a different path.

[sjakobi]

Should stack path do the above things and fail?

No, IMO stack path shouldn't need to have the compiler to return the correct path. I think the build plan should contain sufficient information.

Is there another way to generate the path with stack?

I don't think there is one.

[sjakobi]

BTW have you considered simply specifying the installation directory with --local-bin-path and having stack install copy the executables to that path? That might be simpler than searching for executables in stack-internal paths…

[sjakobi]

Also I'm more doubtful now that stack path can safely run before the paths in question have been created and before the environment has been setup…

@mgsloan: Thoughts on this?

[spl]

@sjakobi I would prefer not to use the ~/.local path, so I haven't been stack install-ing any binaries. But I suppose I could use --local-bin-path to specify a directory in my git repository. That might work. Thanks for the suggestion.

[mgsloan]

There are indeed some portions of stack path that do not need to load as much info. This could also improve the performance of these invocations and allow them to work in more cases.

[neongreen]

I've been bitten by this as well. I wanted to run 4 executables in parallel so I did stack exec 4 times, which failed because stack exec tried running git clone and apparently git doesn't like being run in parallel. I thought stack path --local-install-root wouldn't do this, but it turns out I was wrong.

[mpilgrem]

I am closing this because I think it has been overtaken by the resolution of #6484.