Is there going to be a way to upgrade Stack?

[radix]

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]

+1

[snoyberg]

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

#74

[ndmitchell]

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]

@ndmitchell There's always chocolatey.

[radix]

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]

@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]

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

[3noch]

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

[3noch]

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]

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]

For Mac OSX homebrew support would be great.

[3noch]

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]

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

[snoyberg]

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]

Brilliant.

[snoyberg]

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]

💡 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]

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]

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

[ndmitchell]

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

[snoyberg]

OK, comment added to download page.

[3noch]

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]

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?

[3noch]

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]

@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]

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]

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]

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

[mtolly]

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

[kberger]

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]

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]

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]

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]

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]

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