What exactly is the purpose of `stack install`?

[ra...@twistedmatrix.com]

(This time to the correct mailing list...)

I'm worried that `stack install` may be confusing to people who are used to other package managers^W^Wbuild systems like `pip` and `cabal-install`. My understanding of `stack install` is that it is strictly for installing executables provided by Haskell packages.

1. is this an accurate description of the current reality?

2. is it desired for `stack install` to grow into other things?

If `stack install` is to remain strictly for installing executables, then let me propose that it be renamed to something like `install-exe` to try to avoid confusion for people who are expecting to just use it to install a dependency for a project (like they would in a cabal sandbox or python virtualenv). Maybe it could even print an error if no executables are found in the package.

--

Christopher Armstrong

@radix

[Bob Ippolito]

On Sat, Jul 11, 2015 at 10:58 AM, <ra...@twistedmatrix.com> wrote:

(This time to the correct mailing list...)

I'm worried that `stack install` may be confusing to people who are used to other package managers^W^Wbuild systems like `pip` and `cabal-install`. My understanding of `stack install` is that it is strictly for installing executables provided by Haskell packages.

1. is this an accurate description of the current reality?

I've used it to install libraries globally and play with them in `stack ghci`. Doesn't need to be an executable.

[Michael Snoyman]

I knew that `stack install` would be a point of confusion due to the misuse of the word in cabal :(. See: https://github.com/commercialhaskell/stack/issues/153 for the original discussion.

In sum: using `stack install` on a library is *identical* to `stack build`. The "global" database concept exists in stack, but is completely orthogonal to install vs build. The absolute only difference between install and build is that install copies the executables generated to ~/.local/bin.

Bob: if you want a package available to `stack ghci`, it should be sufficient to run `stack build package-name`.

--
You received this message because you are subscribed to the Google Groups "haskell-stack" group.
To unsubscribe from this group and stop receiving emails from it, send an email to haskell-stac...@googlegroups.com.
To post to this group, send email to haskel...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/haskell-stack/CACwMPm_Saqnf93oQY%3DXnTemrZe0hdastRtfebDugcAJC4Qyexg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Mathieu Boespflug]

I agree that `stack install` as a name is confusing. Not a fan of `install-exe` for the reasons below. This is a topic that came up in the discussion about adding a `stack uninstall` command (on my phone so don't have the ticket number handy).

I think `stack install` as it stands today is a misnomer. Cabal-the-command aspires to *not* be a package manager, which is why it refused to do things such as uninstalls, yet in practice really was a package manager. But stack, unlike Cabal-the-command, is not a package manager, just a build tool. That's true because morally stack's state is purely local to a particular project, which is a repository of source code that needs to be built. The shared sandboxes that stack maintains is just a cache to avoid rebuilding the same packages over and over. Nothing more, nothing less. If the shared sandboxes didn't exist, stack would just be slower, 'tis all. Unlike with cabal-install, there is no user-global package database to maintain, even less a system-global package database. So whereas cabal-install isn't owning up to the reality of being a package manager, stack can still to this day rightfully claim to not be a package manager (and hence avoid all the headaches).

Arguably, a pure build tool should have no `install` command and no `uninstall` command, since the latter especially moves us into package (or at least binaries) management. Perhaps we ought to rename `stack install` to `stack cp`, because that's really what it's doing: copying executables to some implicitly specified location. Then we can have `stack rm` to undo the effect of `stack cp`. Saying `stack cp /some/path` just means the target directory is specified explicitly, overriding any implied default.

The major qualitative difference between "copying" and "installing" is that copying makes no guarantees whatsoever: it's not like the targets of the copy command are considered resources, whose presence is kept track of by registering them in some global index (à la dpkg). The target of a cp command is not "owned" (or managed) by stack in any way. Installation on the other hand provisions the system with new resources. And installation needs to make sure not to clobber these resources ever, and keeping them up-to-date...

--
You received this message because you are subscribed to the Google Groups "haskell-stack" group.
To unsubscribe from this group and stop receiving emails from it, send an email to haskell-stac...@googlegroups.com.
To post to this group, send email to haskel...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/haskell-stack/59ba0d97-3b87-43db-bed2-62313316db30%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Mathieu Boespflug Director of Math and Science Software
FP Complete Corp. 

mobile +33 (0) 7 81 47 02 03 (Central European timezone)

[Michael Snoyman]

I'm on board with such a renaming, especially if we have a graceful deprecation cycle that "stack install" runs "stack cp" with a warning for the next few versions. We could even argue that- in perpetuity- we should keep that behavior around for the users who will assume that `stack install` should exist.

To view this discussion on the web visit https://groups.google.com/d/msgid/haskell-stack/CAJrHAGdGro_GBhWe4UB9M8jy%3DVdC0ZvDfk5ub%3DjO%2BqcxNKwqDQ%40mail.gmail.com.

[Neil Mitchell]

As a Cabal user, I expect "stack install" to exist, and do something
install like. If you want to tell me what it's doing, and say "stack
cp is a better choice" on stdout, that's fine. But if you remove stack
install it's going to be the number 1 FAQ by an absolute mile, and an
FAQ you can predict in advance usually becomes an unnecessary support
burden.

> https://groups.google.com/d/msgid/haskell-stack/CAKA2JgLc4ECAYV6XZrpPfhgMC0R4%2BfJLtQLmdj%2Bs7kM9%2BcD_PQ%40mail.gmail.com.

[Mathieu Boespflug]

Sounds good to me.

[Michael Snoyman]

I think we're all in agreement. I've opened up an issue to summarize and create the work item. If anyone disagrees, please give a shout:

https://github.com/commercialhaskell/stack/issues/569

To view this discussion on the web visit https://groups.google.com/d/msgid/haskell-stack/CAJrHAGf8eMkz2Ctd5x9veEDSY0OZEtHHdFMi32Wv1P4Pm48pHg%40mail.gmail.com.

[Simon Michael]

I strongly disagree. Renaming or removing this command is what would be confusing. Surely it can and should be improved, but even now it's a big step forward. A simple reliable way to install haskell things is the number one most useful thing stack provides.