Stack: Stack install should take a --path option

[drwebb]

I tend to keep my user binaries in ~/bin instead of ~/.local/bin. The directory path seems to be set in.

src/Stack/Config.hs
186:        localDir <- liftIO (getAppUserDataDirectory "local") >>= parseAbsDir

getAppUserDataDirectory is defined in System.Directory. Is it should return $HOME/.local always, so it doesn't appear to be able to take a flag or anything. The install function takes both BuildOpts and GlobalOpts parameters, so perhaps such a parameter could live in one of there as a Maybe and be passed as a --path option from the command line.

https://github.com/commercialhaskell/stack/blob/118cb3ed42ff6aba02b5acdea19e6c2cbbc52302/src/main/Main.hs#L346

[cdepillabout]

I do a similar thing. This feature would be nice to have.

[gregwebs]

I was a bit surprised to see ~/.local used as the install dir. ~/.stack/bin would make more sense as a default to me.

[snoyberg]

See the discussion in #153

[chreekat]

That was my idea, here. It's a standard-that-isn't, but one I'm comfortable pushing towards being de facto.

[bitemyapp]

@chreekat re: ~/.local – is this that XDG thing Arch Linux users bring up?

[chreekat]

@bitemyapp ~/.local is XDG, yes. ~/.local/bin is not specified (yet). As I mentioned in my linked comment, it's nonetheless supported and used by other projects already.

[gregwebs]

I like the idea of ~/.local/bin except that it increases the chance of having a collision.

[snoyberg]

But the point of installing is to make the binary available _outside_ the stack world. For within stack, you can just use stack build and stack adds it to the local PATH. stack install is specifically when you want the executable to be available for other purposes.

[chreekat]

Adding it to XDG seemed to stall, if I read the Fedora thread I linked to in my linked comment correctly, because it was new and therefore scary to seasoned UNIX veterans.

e.g., "Oh it seems very useful for purposes like installing executables that most users will never find." and "[The arguments for adding it are] bogus because this is the first I've heard of ~/.local/bin, speaking as a Unix user since long before Linux existed."

@gregwebs that's a fair point — once we're installing into a "standardized" location, we're back at needing a system-wide package manager to manage conflicts. Yikes?

[bitemyapp]

@chreekat I think ~/.local/bin could be fine since system package managers don't use it. It's not clear to me what the alternative would be since /usr/bin is system level and nobody's really got a consistent story for /usr/local/bin and having a diaspora of ~/.*/bin is obnoxious.

OTOH, I've found adding ~/.cabal/bin to my path in programs like Emacs sufficiently unreliable that I've given up and just symlink things from my ~/.cabal/bin into my /usr/bin because that's the only thing I've done that works 100% of the time without configuration.

[drwebb]

@snoyberg This is actually blocking me slightly on #353, where I want to use stack to build the git version of it self inside a chroot. I just want to put install the bin to a fixed location relative to the build directory. It seems like a straightforward addition to me. Do you have any thoughts on where the flag should go, in BuildOps or GlobalOps?

[snoyberg]

Neither. It should only apply to the install command.

[drwebb]

@snoyberg code review requested for my proposed changes at
https://github.com/commercialhaskell/stack/compare/specifypath

I'll want to add support for relative dirs before opening a PR.

[snoyberg]

It's easier to comment on a PR than a compare, so I'll hold off comments until that's ready.

[leahneukirchen]

It would also be useful if stack install could behave like cabal copy, and install more than only the actual binaries. Perhaps a --destdir flag would be enough?

[zimbatm]

It's probably a good time to ask if stack is expected to generate anything else than binaries ? Usually make install kind of commands accept a prefix and then make the assumption that $prefix/bin is where binaries belong. Even if today stack only produces binaries in the longer term it's probably better to follow that convention.

[radix]

@zimbatm Personally I don't think it's a good idea to make stack a user-facing installation tool. It's meant for developers, and it's annoying as a user to have to install something like stack before being able to install some program I want to run.

However, I think it would be a _great_ idea for stack to have plugins to create distributable artifacts in various formats: for example, windows MSIs , Debs, RPMs, etc.

[zimbatm]

@radix actually the use-case I have in mind is packaging. Most of them want an install to "$DEST/$PREFIX" where DEST is a temporary root and PREFIX is the path where the files will end up once installed. Eg: DEST=/tmp/<package-name>.<unique-id> PREFIX=/usr . The binaries is going to end up in /tmp/<package-name>.<unique-id>/usr/bin/<binary-name>. The package manager is going to archive /tmp/<package-name>.<unique-id> and /usr/bin/<binary-name> is where the binary is going to be installed. Producing packages using fpm is easy after that and it's also going to integrate with existing tooling. Especially debian packages, if you want to distribute your own debian packages it's fine but if you want to be distributed by mainline repos then you have to obey to all of their weird tooling.

[radix]

@zimbatm so ok, then that just means in your debian script (or whatever) you'll just need to invoke stack install --path $DEST/bin, so I'm not sure stack needs to grow any more features to support that case.

[leahneukirchen]

This is exactly my usecase (as a packager) and some Haskell software (e.g. pandoc) installs also to /usr/share...

[drwebb]

Functionality for stack install --local-bin-path <dir> is now in master.