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

Improved PATH-aware behavior for stack upgrade #3232

Closed
snoyberg opened this issue Jun 27, 2017 · 0 comments
Closed

Improved PATH-aware behavior for stack upgrade #3232

snoyberg opened this issue Jun 27, 2017 · 0 comments

Comments

@snoyberg
Copy link
Contributor

@snoyberg snoyberg commented Jun 27, 2017

Problem: users will often run the install script and end up with stack in /usr/local/bin, and when they run stack upgrade, are surprised that the next stack call still uses the old version. To mitigate this, @borsboom and I propose:

  1. stack upgrade continues to copy the executable to ~/.local/bin as it has until now
  2. If the current Stack executable is running from there: we're done. Otherwise: continue.
  3. Attempt to copy the stack executable to the location of the current executables.
  4. If that fails with a permission denied error:
    1. Explain the situation to the user, and recommend copying from source file path to dest file path
    2. Ask if the user wants us to try to use sudo to perform the copy (and explain that it may fail due to OS specific things)
    3. If the user says yes, try running sudo cp ..., and potentially similar commands with su.

Presumably we won't even bother trying this on Windows.

snoyberg added a commit that referenced this issue Jun 27, 2017
snoyberg added a commit that referenced this issue Jul 13, 2017
borsboom added a commit that referenced this issue Jul 19, 2017
* Fix typo in tryIO

* Perform path check on stack upgrade #3232
@borsboom borsboom closed this Jul 19, 2017
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