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

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

Comments

Projects
None yet
10 participants
@radix
Contributor

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

This comment has been minimized.

Show comment
Hide comment
@bitemyapp

bitemyapp Jun 9, 2015

Contributor

+1

Contributor

bitemyapp commented Jun 9, 2015

+1

@snoyberg

This comment has been minimized.

Show comment
Hide comment
@snoyberg

snoyberg Jun 9, 2015

Contributor

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

#74

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@ndmitchell

ndmitchell Jun 9, 2015

Contributor

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.

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@3noch

3noch Jun 9, 2015

Member

@ndmitchell There's always chocolatey.

Member

3noch commented Jun 9, 2015

@ndmitchell There's always chocolatey.

@radix

This comment has been minimized.

Show comment
Hide comment
@radix

radix Jun 9, 2015

Contributor

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.

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@3noch

3noch Jun 10, 2015

Member

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

Member

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

This comment has been minimized.

Show comment
Hide comment
@radix

radix Jun 10, 2015

Contributor

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

Contributor

radix commented Jun 10, 2015

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

@3noch

This comment has been minimized.

Show comment
Hide comment
@3noch

3noch Jun 10, 2015

Member

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

Member

3noch commented Jun 10, 2015

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

@3noch

This comment has been minimized.

Show comment
Hide comment
@3noch

3noch Jun 10, 2015

Member

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.

Member

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

This comment has been minimized.

Show comment
Hide comment
@snoyberg

snoyberg Jun 10, 2015

Contributor

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.
Contributor

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

This comment has been minimized.

Show comment
Hide comment
@newzealandpaul

newzealandpaul Jun 10, 2015

For Mac OSX homebrew support would be great.

For Mac OSX homebrew support would be great.

@3noch

This comment has been minimized.

Show comment
Hide comment
@3noch

3noch Jun 10, 2015

Member

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.

Member

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

This comment has been minimized.

Show comment
Hide comment
@3noch

3noch Jun 10, 2015

Member

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

Member

3noch commented Jun 10, 2015

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

@snoyberg

This comment has been minimized.

Show comment
Hide comment
@snoyberg

snoyberg Jun 10, 2015

Contributor

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".

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@3noch

3noch Jun 10, 2015

Member

Brilliant.

Member

3noch commented Jun 10, 2015

Brilliant.

@snoyberg

This comment has been minimized.

Show comment
Hide comment
@snoyberg

snoyberg Jun 15, 2015

Contributor

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

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@rvion

rvion Jun 15, 2015

Contributor

💡 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

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@snoyberg

snoyberg Jun 15, 2015

Contributor

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.

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@rvion

rvion Jun 15, 2015

Contributor

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

Contributor

rvion commented Jun 15, 2015

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

@ndmitchell

This comment has been minimized.

Show comment
Hide comment
@ndmitchell

ndmitchell Jun 15, 2015

Contributor

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

Contributor

ndmitchell commented Jun 15, 2015

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

@snoyberg

This comment has been minimized.

Show comment
Hide comment
@snoyberg

snoyberg Jun 15, 2015

Contributor

OK, comment added to download page.

Contributor

snoyberg commented Jun 15, 2015

OK, comment added to download page.

@snoyberg snoyberg closed this Jun 15, 2015

@3noch

This comment has been minimized.

Show comment
Hide comment
@3noch

3noch Jun 22, 2015

Member

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
Member

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

This comment has been minimized.

Show comment
Hide comment
@snoyberg

snoyberg Jun 22, 2015

Contributor

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?

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@3noch

3noch Jun 22, 2015

Member

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.

Member

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

This comment has been minimized.

Show comment
Hide comment
@bitemyapp

bitemyapp Jun 22, 2015

Contributor

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

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@snoyberg

snoyberg Jun 23, 2015

Contributor

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.
Contributor

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

Implement an upgrade command #237
Also implemented #378 along the way
@snoyberg

This comment has been minimized.

Show comment
Hide comment
@snoyberg

snoyberg Jun 26, 2015

Contributor

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.

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@snoyberg

snoyberg Jun 27, 2015

Contributor

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

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@mtolly

mtolly Jul 1, 2015

Contributor

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

Contributor

mtolly commented Jul 1, 2015

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

@kberger

This comment has been minimized.

Show comment
Hide comment
@kberger

kberger 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.

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

This comment has been minimized.

Show comment
Hide comment
@snoyberg

snoyberg Jul 31, 2015

Contributor

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)
.

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@kberger

kberger 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.

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

This comment has been minimized.

Show comment
Hide comment
@snoyberg

snoyberg Jul 31, 2015

Contributor

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).

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@kberger

kberger 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.

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.

@kberger kberger referenced this issue in yesodweb/yesod Jul 31, 2015

Closed

Issue creating keter package with stack #1048

@drwebb

This comment has been minimized.

Show comment
Hide comment
@drwebb

drwebb Aug 2, 2015

Contributor

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

Contributor

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

@wolftune wolftune referenced this issue in snowdriftcoop/snowdrift Aug 11, 2015

Closed

Added stack.yaml extra-deps required for Windows build #316

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment