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

[sjakobi]

~/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]

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]

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]

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]

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.

[mgsloan]

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

[sjakobi]

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]

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]

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.

[sjakobi]

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.