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

Is there going to be a way to upgrade Stack? #237

Closed
radix opened this issue Jun 9, 2015 · 35 comments
Closed

Is there going to be a way to upgrade Stack? #237

radix opened this issue Jun 9, 2015 · 35 comments
Assignees
Milestone

Comments

@radix
Copy link
Contributor

@radix radix commented Jun 9, 2015

Say I've installed Stack by downloading the binary distribution for Mac OS X -- it'd be nice if I could just run something like "stack upgrade-stack" to get a new release -- and also, for stack to notify when there's a new version, a la Python's pip tool.

@bitemyapp
Copy link
Contributor

@bitemyapp bitemyapp commented Jun 9, 2015

+1

@snoyberg
Copy link
Contributor

@snoyberg snoyberg commented Jun 9, 2015

There's an open issue for discussing this point, which we do need to get a solid answer to:

#74

@ndmitchell
Copy link
Contributor

@ndmitchell ndmitchell commented Jun 9, 2015

I see the two issues as separate. One is about how you typically do a first install. One is about how you do an update. On Linux these might be the same, but on Windows you want to copy a binary the first time then stack upgrade afterwards.

@3noch
Copy link
Member

@3noch 3noch commented Jun 9, 2015

@ndmitchell There's always chocolatey.

@radix
Copy link
Contributor Author

@radix radix commented Jun 9, 2015

If stack grows a way to install packages to the system (whether in /usr or in ~/.local or whatever), then it would make sense for the upgrade process to just be to use that mechanism. (stack install --upgrade stack?)

To make this interoperate with the initially downloaded binary, perhaps lein could be used as an inspiration: when you download lein, you're just getting a shell script, which checks if lein is installed in the user's home directory in the expected location, and then invokes that. If not, it downloads and installs the latest version. This means that even if the package isn't "really" installed, the first time the user runs lein, it's installed properly.

Of course this mostly just applied to OS X and Unix, but I guess the same general idea can be applied to Windows as well. It's just that you can't rely on a simple shell script in that case.

@3noch
Copy link
Member

@3noch 3noch commented Jun 10, 2015

@radix So lein has some sort of proxy script that does update-checking/downloading before running an actual app? Instead of a script, you could do that with a thin executable binary that would be cross-platform.

@radix
Copy link
Contributor Author

@radix radix commented Jun 10, 2015

@3noch yeah, good point. bash isn't a great language to write software in :)

@3noch
Copy link
Member

@3noch 3noch commented Jun 10, 2015

@radix Haskell's ability to run on bare metal is a huge selling point in my book!

@3noch
Copy link
Member

@3noch 3noch commented Jun 10, 2015

FWIW, "binary that would be cross-platform" would of course mean we'd need several binaries, one for each platform, but the code would be the same.

@snoyberg snoyberg added this to the First stable release (0.1.0.0?) milestone Jun 10, 2015
@snoyberg
Copy link
Contributor

@snoyberg snoyberg commented Jun 10, 2015

What if stack itself had this logic, something along the lines of:

  • If I'm not being run from ~/.local/bin (and equivalent on Windows), check if ~/.local/bin/stack exists and, if so, call it with the same arguments as I received
  • Otherwise, just run
  • To upgrade: you run stack install-exe stack (or whatever we call that command), optionally making an upgrade-stack command that does much the same thing.
@newzealandpaul
Copy link

@newzealandpaul newzealandpaul commented Jun 10, 2015

For Mac OSX homebrew support would be great.

@3noch
Copy link
Member

@3noch 3noch commented Jun 10, 2015

My only thought is that now you really have two (or more) versions of a working stack on your computer that have a pretty strange relationship. It might be better to have a thin "stack runner" that is both smaller (in terms of executable size) and simpler (in terms of functionality). That runner had better never change, because you can't upgrade it. But once you have it, it would keep track of its own stack versions, install locations, etc.

@3noch
Copy link
Member

@3noch 3noch commented Jun 10, 2015

I slightly fear stack upgrading itself to change the way it upgrades itself and then breaking...

@snoyberg
Copy link
Contributor

@snoyberg snoyberg commented Jun 10, 2015

Now that I've got the stack install command set up in such a way that it can write to the same file it's running from, I'm less interested in the wrapper approach and would like to consider a simple stack install stack upgrade process. You're correct to be concerned about upgrading and breaking itself. One possibility is to automatically back up the current executable instead of wiping it out and notifying the user "your old stack is available at filepath".

@3noch
Copy link
Member

@3noch 3noch commented Jun 10, 2015

Brilliant.

@snoyberg
Copy link
Contributor

@snoyberg snoyberg commented Jun 15, 2015

stack install stack or stack install stack:latest both work now. Any objection to closing this issue (likely with a documentation update to match)?

@rvion
Copy link
Contributor

@rvion rvion commented Jun 15, 2015

💡 I would leave it open until doc is written.
I would also add a need doc label to keep track of it.

docker does this to keep doc in sync, it would benefit to this project I think

@snoyberg
Copy link
Contributor

@snoyberg snoyberg commented Jun 15, 2015

There is a documentation label already. My intent in the previous comment was: if everyone's happy with the behavior, let's update the docs and close this. I don't want to tell everyone "this is how you upgrade" in the docs unless we agree that this is the right way to upgrade.

@rvion
Copy link
Contributor

@rvion rvion commented Jun 15, 2015

oups, got it, thanks for the explanation (and all that amazing work)

@ndmitchell
Copy link
Contributor

@ndmitchell ndmitchell commented Jun 15, 2015

Sounds perfect, since it exactly matches Cabal (at least the first one does).

@snoyberg
Copy link
Contributor

@snoyberg snoyberg commented Jun 15, 2015

OK, comment added to download page.

@snoyberg snoyberg closed this Jun 15, 2015
@3noch
Copy link
Member

@3noch 3noch commented Jun 22, 2015

I can't get the upgrade to work, I always get an error akin to the following:

> stack update && stack install stack:latest
Updating package index Hackage (mirrored at https://github.com/commercialhaskell
Fetched package index.
Using resolver: lts-2.15 from global config file: C:\Users\Elliot Cameron\AppData\Roaming\stack\global\stack.yaml
Populated index cache.
While constructing the BuildPlan the following exceptions were encountered:

--  While attempting to add dependency,
    Could not find package path in known packages

--  Failure when adding dependencies:
      path: needed (-any && >=0.5.1), but not present in build plan, latest is 0.5.2
    needed for package: stack-0.0.3

Recommended action: try adding the following to your extra-deps in C:\Users\Elliot Cameron\AppData\Roaming\stack\global\stack.yaml
- path-0.5.2
@snoyberg snoyberg modified the milestones: 0.2.0.0, 0.1.0.0 Jun 22, 2015
@snoyberg snoyberg self-assigned this Jun 22, 2015
@snoyberg
Copy link
Contributor

@snoyberg snoyberg commented Jun 22, 2015

This is a good point, we do need a different upgrade path. Options:

  1. Include a stack.yaml in the tarball, and have stack use that
  2. Use dependency solving
  3. Upgrade via the Git repo instead of from Hackage
  4. Have stack get out of the update business. On Linux distros, allow the package manager to handle update. On Mac and Windows, users would need to download new versions.

I favor (1), and then maybe having a special stack upgrade which will be essentially the same as stack unpack stack && cd stack-* && stack setup && stack install. Thoughts?

@snoyberg snoyberg reopened this Jun 22, 2015
@3noch
Copy link
Member

@3noch 3noch commented Jun 22, 2015

I'll leave the discussion up to you guys. I don't have a good sense of the answer. I don't particularly relish the thought of (4) since I'm imprisoned by Window's lack of a good package management system.

@bitemyapp
Copy link
Contributor

@bitemyapp bitemyapp commented Jun 22, 2015

@3noch I don't favor it either, but Windows users have been converging on using things like Chocolatey – I mention this not because I think Stack should rely on such things in Windows but so that you know it exists in case you did not.

snoyberg added a commit that referenced this issue Jun 23, 2015
@snoyberg
Copy link
Contributor

@snoyberg snoyberg commented Jun 23, 2015

Actually, there's a much simpler solution that I should have realized: just wait. Once stack is included in LTS 3.0, installing it will work correctly.

That said, having some kind of a command for stack to automatically unpack/init/setup/install sounds like it would be generally useful. Giving it the option of a command line switch to instead clone from Git to get the bleeding edge would be nice too (and would address https://twitter.com/ndm_haskell/status/613024085220716544).

So my proposed next steps:

  • Add some flag to install that will do the unpack/setup/optional init/install thing
  • Add another flag for both install and unpack that will trigger unpacking from Git instead of from the tarball
  • Optionally: add a command stack upgrade which is the same as stack install stack with the appropriate extra flags turned on.
@snoyberg snoyberg added ready and removed in progress labels Jun 24, 2015
snoyberg added a commit that referenced this issue Jun 26, 2015
Also implemented #378 along the way
@snoyberg
Copy link
Contributor

@snoyberg snoyberg commented Jun 26, 2015

I've just pushed a commit which adds stack upgrade. Details:

  • It takes a --git flag to clone the latest git master
  • Without --git it won't work right now because the stack on Hackage doesn't have a stack.yaml file
  • It doesn't currently check if the current stack version is newer than what it's trying to install. I'm guessing it should, but I'm open to input
  • It follows the same needs around having a GHC installed that matches stack.yaml. I debated about this, and decided it was the only way we could really guarantee a good build, which is our goal.

If anyone wants to test it out, that would be great.

@snoyberg
Copy link
Contributor

@snoyberg snoyberg commented Jun 27, 2015

I'm going to mark as resolved for now, if issues pop up, let's discuss in a new issue.

@snoyberg snoyberg closed this Jun 27, 2015
@snoyberg snoyberg removed the ready label Jun 27, 2015
@mtolly
Copy link
Contributor

@mtolly mtolly commented Jul 1, 2015

stack upgrade --git worked great for me on OS X (upgraded from 0.1.1.0 to bf086c6).

@kberger
Copy link

@kberger kberger commented Jul 31, 2015

What's the relationship with ~/.local/bin? After running 'stack upgrade --git' I now have two instances of stack installed:

karl@thenorth:~/code/web_personal$ which stack; stack --version
/usr/bin/stack
Version 0.1.2.0, Git revision 65246552936b7da4b64b38372feac903d96a8911 (dirty)

which was installed and I assume is controlled by the package from the PPA as directed by the Readme
and

karl@thenorth:~/code/web_personal$ ~/.local/bin/stack --version
Version 0.1.2.2, Git revision df9a810d441d69f1749ca41a5f6fa27c297cf700

which was installed by the upgrade.

If this is the desired result, better documentation is needed to explain the two instances.

@snoyberg
Copy link
Contributor

@snoyberg snoyberg commented Jul 31, 2015

This information is actually covered on the Downloads page:

https://github.com/commercialhaskell/stack/wiki/Downloads#path

If you see a way to clarify the situation, please update the docs, it will
be much appreciated!

On Fri, Jul 31, 2015 at 12:24 PM, Karl Berger notifications@github.com
wrote:

What's the relationship with ~/.local/bin? After running 'stack upgrade
--git' I now have two instances of stack installed:

karl@thenorth:~/code/web_personal$ which stack; stack --version
/usr/bin/stack
Version 0.1.2.0, Git revision 6524655 (dirty)

which was installed and I assume is controlled by the package from the PPA
as directed by the Readme
and

karl@thenorth:~/code/web_personal$ ~/.local/bin/stack --version
Version 0.1.2.2, Git revision df9a810

which was installed by the upgrade.

If this is the desired result, better documentation is needed to explain
the two instances.


Reply to this email directly or view it on GitHub
#237 (comment)
.

@kberger
Copy link

@kberger kberger commented Jul 31, 2015

Haha, I feel like such a user for not reading the docs in detail.

For clarification, the 'advantageous' thing to do would be to move the stack executable out of /usr/bin/stack to ~/.local/bin and add that directory to my PATH? Should I then just ignore upgrades that come via the PPA/apt and just make sure I 'stack upgrade' from time to time? Just want to make sure I've got the workflow down.

@snoyberg
Copy link
Contributor

@snoyberg snoyberg commented Jul 31, 2015

Here's the idea:

  • PPA/debs/RPMs/etc install to a global location and are tracked by the package manager
  • If you want to customize that/live on the bleeding edge/not use a package manager: use stack upgrade
  • Place ~/.local/bin in front of the global bin directories so that overriding works
  • If you screw up your local stack, you can always rm ~/.local/bin/stack and start over with the global one

This isn't really any kind of hard-coded rule, just commonly evolving patterns that people use. Actually, I used the exact some workflow with cabal as well (~/.cabal/bin in front of /opt/cabal/1.22/bin).

@kberger
Copy link

@kberger kberger commented Jul 31, 2015

That all sounds quite reasonable, thanks. I should have taken a bigger hint from upgrade being marked "experimental" and figured that I probably didn't want that just blasting away the "stable" install.

@drwebb
Copy link
Contributor

@drwebb drwebb commented Aug 2, 2015

With Arch, for the next release, the git version and the stable release
version will be built from the same script, or rather we will build stable
binary using the haskell-stack-git PKGBUILD held at the right tag and put
that up on AWS to be sourced in the stable PKGBUILD. So one bootstraps
their system with the binary version and then they can switch switch from
stable to the git version at any time and visa versa using the system
package manager.

On Fri, Jul 31, 2015 at 12:41 PM, Karl Berger notifications@github.com
wrote:

That all sounds quite reasonable, thanks. I should have taken a bigger
hint from upgrade being marked "experimental" and figured that I probably
didn't want that just blasting away the "stable" install.


Reply to this email directly or view it on GitHub
#237 (comment)
.

Tristan Webb PhD
Haskell Application Engineer
FP Complete
San Diego, CA
M: 619-452-9545

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
10 participants
You can’t perform that action at this time.