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

Running `stack config set resolver X` inside a project modifies the global project's stack.yaml #2709

Closed
sjakobi opened this issue Oct 13, 2016 · 9 comments

Comments

@sjakobi
Copy link
Member

@sjakobi sjakobi commented Oct 13, 2016

~/tmp $ stack new repro
...
~/tmp $ cd repro/
~/t/repro $ stack config set resolver nightly
Selected resolver: nightly-2016-10-13
/home/simon/.stack/global-project/stack.yaml has been updated.

This bug probably crept in during 0bdab6e.

I think I missed that the Config that I get from withMiniConfigAndLock doesn't contain any information on the current project, so getStackYaml always ends up looking for the global project.

I probably won't get around to fixing this until Sunday…

I also think that it would be good to have safeguards against bugs like this, for example by assigning different types to Configs from MiniConfigs and BuildConfigs or something similar.

@sjakobi sjakobi added the type: bug label Oct 13, 2016
@sjakobi sjakobi added this to the P1: Must milestone Oct 13, 2016
@sjakobi
Copy link
Member Author

@sjakobi sjakobi commented Oct 13, 2016

A fix would probably keep the command running in withMiniConfigAndLock but use an appropriate method to look for the project stack.yaml on the filesystem.

@sjakobi
Copy link
Member Author

@sjakobi sjakobi commented Oct 17, 2016

Strange, I can't reproduce the issue now using

$ stack --version
Version 1.2.1, Git revision b6ab1f949c7884b7ccfb07f7e66f073726565b34 (dirty) (4239 commits) x86_64 hpack-0.14.1

Not sure what version of stack I was using when I ran into this. :(

@sjakobi
Copy link
Member Author

@sjakobi sjakobi commented Oct 17, 2016

Well, I assume I was using some dev version of stack, that I had built while working on 0bdab6e.

Regarding

I think I missed that the Config that I get from withMiniConfigAndLock doesn't contain any information on the current project, so getStackYaml always ends up looking for the global project.

I guess I confused withMiniConfig with withGlobalConfigAndLock here.

Consequently closing as "false alarm". If anyone else can reproduce the issue, please reopen.

@sjakobi sjakobi closed this Oct 17, 2016
@sjakobi
Copy link
Member Author

@sjakobi sjakobi commented Jan 13, 2017

This bug has popped up again:

~/tmp $ stack new repro2709
...
Initialising configuration using resolver: lts-7.15
Total number of user packages considered: 1
Writing configuration to file: repro2709/stack.yaml
All done.
~/tmp $ cd repro2709/
~/t/repro2709 $ stack config set resolver nightly
Selected resolver: nightly-2017-01-13
/home/simon/.stack/global-project/stack.yaml already contained the intended configuration and remains unchanged.
~/t/repro2709 $ stack --version
Version 1.3.2, Git revision 3f675146590da4f3edf768b89355f798229da2a5 (4395 commits) x86_64 hpack-0.15.0

I guess this is a side effect of d0eabec.

@sjakobi sjakobi reopened this Jan 13, 2017
mgsloan added a commit that referenced this issue Feb 1, 2017
@mgsloan
Copy link
Contributor

@mgsloan mgsloan commented Feb 1, 2017

@sjakobi Good catch! I've pushed a fix.

@mgsloan mgsloan closed this Feb 1, 2017
@sjakobi
Copy link
Member Author

@sjakobi sjakobi commented Feb 1, 2017

Thanks for taking care of this but I don't think your fix works at intended.

In particular I can't figure out how to apply that --global flag to apply the change to the global project.

I'm also not convinced that the --global flag should be necessary to change the global project. Instead, when in the "global project scope", stack config set resolver should apply to the global project.

There's also a this debug print statement that should be removed.

~/t/repro2709 $ stack config set resolver nightly
(CommandScopeProject,"/home/simon/tmp/repro2709/stack.yaml")
Selected resolver: nightly-2017-02-01
Downloaded nightly-2017-02-01 build plan.    
/home/simon/tmp/repro2709/stack.yaml has been updated.
~/t/repro2709 $ cd
~ $ stack config set resolver nightly
Since --global was not used, expected to find a local project configuration.  However, none was found.
~ $ stack --global config set resolver nightly
Invalid option `--global'

Usage: stack [--help] [--version] [--numeric-version] [--hpack-numeric-version]
             [--docker*] [--nix*] ([--verbosity VERBOSITY] | [-v|--verbose] |
             [--silent]) [--[no-]time-in-log] [--stack-root STACK-ROOT]
             [--work-dir WORK-DIR] [--[no-]system-ghc] [--[no-]install-ghc]
             [--arch ARCH] [--ghc-variant VARIANT] [--ghc-build BUILD]
             [-j|--jobs JOBS] [--extra-include-dirs DIR] [--extra-lib-dirs DIR]
             [--with-gcc PATH-TO-GCC] [--[no-]skip-ghc-check] [--[no-]skip-msys]
             [--local-bin-path DIR] [--[no-]modify-code-page]
             [--[no-]allow-different-user] [--[no-]dump-logs]
             [--resolver RESOLVER] [--compiler COMPILER] [--[no-]terminal]
             [--color WHEN] [--stack-yaml STACK-YAML] COMMAND|FILE
~ $ stack config set resolver nightly --global
Invalid option `--global'

Usage: stack config set resolver RESOLVER
  Change the resolver of the current project. See
  https://docs.haskellstack.org/en/stable/yaml_configuration/#resolver for more
  info.
~ $ stack config set --global resolver nightly
Invalid option `--global'

Usage: stack config set COMMAND [--help]
  Sets a field in the project's stack.yaml to value
~ $ stack config --global set resolver nightly
Invalid option `--global'

Usage: stack config COMMAND|FILE [--help]
  Subcommands specific to modifying stack.yaml files
@sjakobi sjakobi reopened this Feb 1, 2017
@sjakobi
Copy link
Member Author

@sjakobi sjakobi commented Feb 1, 2017

Oh yeah, I realize that I am now myself confused about the "global project" and the --global flag in the context of the stack config command.

For stack config set system-ghc and stack config set install-ghc, --global means the ~/.stack/config.yaml while usually, by "global" we mean the "implicit global project".

I really think we need a better terminology here.

Maybe call the ~/.stack/config.yaml the "user config" (and change the flag name to --user)…

mgsloan added a commit that referenced this issue Feb 1, 2017
@mgsloan
Copy link
Contributor

@mgsloan mgsloan commented Feb 1, 2017

Doh, thanks for catching those mistakes! I've pushed a fix.

Yeah, I was indeed thinking that --global meant the global project, not config. Maybe not the best flag naming, but at least --help clarifies properly.

@mgsloan mgsloan closed this Feb 1, 2017
@sjakobi
Copy link
Member Author

@sjakobi sjakobi commented Feb 2, 2017

Doh, thanks for catching those mistakes! I've pushed a fix.

Looks good now!

Yeah, I was indeed thinking that --global meant the global project, not config. Maybe not the best flag naming, but at least --help clarifies properly.

I think it's a bad sign that this issue confuses even the developers, so IMHO the sooner this issue is fixed, the better. I still assume that stack is going to have more users in the future than it has had so far, so I believe that these kinds of investments are worthwhile.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants
You can’t perform that action at this time.