`stack script` ignores `local-programs-path` in ~/.stack/config.yaml

[sgraf812]

General summary/comments

Also found #3705, so I assume stack script ignores ~/.stack/config.yaml completely.

Steps to reproduce

For example:

1. Edit ~/.stack/config.yaml with a setting for local-programs-path to point somewhere else than ~/.stack/programs
2. Run stack stream-fusion.hs, where stream-fusion.hs is the attached file

Expected

Just run the thing after initial setup

Actual

Re-downloads GHC 8.2.2 and errors (might be machine-specific) while unpacking it into ~/.stack/programs. Also complains with The following directories may now contain files, but won't be used by stack <some ~/.stack/programs paths>, which it wouldn't in the first place.

$ stack stream-fusion.hs --verbose
Already downloaded.
Unpacking GHC into /$HOME/.stack/programs/x86_64-linux/ghc-nopie-8.2.2.temp/ ...

Stack version

$ stack --version
Version 1.6.5, Git revision 24ab0d6ff07f28276e082c3ce74dfdeb1a2ca9e9 (5514 commits) x86_64 hpack-0.20.0

Method of installation

Installed 1.6.3 through nix-env, but then did stack upgrade and used the downloaded exe for this reproduction (didn't want to wait for the upgrade of my whole distribution).

[sgraf812]

Worked around this by just symlinking ~/.stack somewhere else altogether.

[mgsloan]

Yes, it looks like stack script does not read config.yaml. This is likely for reproducibility, but I'm thinking that it should read it. The reasoning is that the options allowed in config.yaml are mostly intended to configure stack to work properly with their system and change some CLI defaults. So, hopefully having stack script read config.yaml would not greatly negatively affect reproducibility, and instead just allow scripts to work in more cases.

Pinging @snoyberg should stack script read config.yaml?

[snoyberg]

I don't know all of the different options allowed in config.yaml, but I'm imagining some of them should be allowed, and others shouldn't. local-programs-path seems like one that should be parsed by script.

[dbaynard]

don't know all of the different options allowed in config.yaml, but I'm imagining some of them should be allowed, and others shouldn't. local-programs-path seems like one that should be parsed by script.

I've just run into this with ghc-build (though I don't remember why I set it the first place — I think I set it when I encountered issues on arch, and right now I don't want to re-download all the versions of ghc). My workaround is to specify --ghc-build=tinfo6-nopie on the command line.

It is not obvious that the config isn't read, either.

Anyway, I've split the options as far as I can tell into those which are likely safe to read for the script command. If that looks ok, then there's a concrete way forward with this issue.

---

Safe, i.e. build may fail on a user’s machine because of that user’s setup

• docker
• nix
• connection-count
• hide-th-loading
• local-bin-path
• system-ghc
• install-ghc
• require-stack-version
• arch/os
• with-gcc
• with-hpack
• ghc-variant
• ghc-build
• setup-info
• pvp-bounds
• modify-code-page
• explicit-setup-deps
• dump-logs
• templates
• save-hackage-creds
• hackage-base-url
• jobs
• work-dir
• skip-msys
• concurrent-tests
• local-programs-path
• default-template
• color
• stack-colors

Unsafe, i.e. scripts created with these options set in config.yaml may not be reproducible on systems without the changes they imply

• latest-snapshot-url
• extra-include-dirs/extra-lib-dirs
• ghc-options
• apply-ghc-options
• rebuild-ghc-options
• allow-newer (I’ve been bitten by this multiple times, and yet always forget it)
• build
• ignore-revision-mismatch
• urls

Maybe safe (it’s possible for irreproducible builds? I wasn’t sure)

• package-indices
• skip-ghc-check
• compiler-check
• compiler
• allow-different-user (do we want this to be allowed for the script command?)
• extra-path

[snoyberg]

I'm going to make this change