Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
sgraf812 opened this issue Feb 23, 2018 · 5 comments

Comments

Projects
None yet
4 participants
@sgraf812
Copy link
Contributor

commented Feb 23, 2018

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

This comment has been minimized.

Copy link
Contributor Author

commented Feb 23, 2018

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

@mgsloan

This comment has been minimized.

Copy link
Collaborator

commented Feb 25, 2018

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?

@mgsloan mgsloan added the type: bug label Feb 25, 2018

@mgsloan mgsloan added this to the P2: Should milestone Feb 25, 2018

@snoyberg

This comment has been minimized.

Copy link
Contributor

commented Feb 26, 2018

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

This comment has been minimized.

Copy link
Contributor

commented Dec 4, 2018

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

This comment has been minimized.

Copy link
Contributor

commented Apr 1, 2019

I'm going to make this change

snoyberg added a commit that referenced this issue Apr 5, 2019

Rename NoConfig to NoProject
This also changes the behavior: we _do_ load up the user config file,
just no project config file.

* Fixes #3705
* Fixes #3887

snoyberg added a commit that referenced this issue Apr 5, 2019

Rename NoConfig to NoProject
This also changes the behavior: we _do_ load up the user config file,
just no project config file.

* Fixes #3705
* Fixes #3887
* Fixes #4699
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.