Description
In particular, this is an issue if the current project uses Docker integration, since the new stack
binary will be installed in ~/.local/bin
in the container (and that binary may not be compatible with the host's platform), which is almost certainly not intended since that stack binary won't ever actually be used.
While we could force stack upgrade
to disable Docker integration, there are cases where the rest of the project's stack.yaml
don't make sense in a non-Docker context and so it would fail. Therefore, better to just have stack upgrade
always use the implicit global project in ~/.stack/global-project
.
Steps to reproduce:
- Create a project with a stack.yaml that enables Docker integration
- Run
stack upgrade
in the project
Expected results:
stack --version
shows that stack has been upgraded on the host.
Actual results:
stack --version
on the host is unchanged, since the new stack
executable was only installed in the container.