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.

stack/src/main/Main.hs

Line 346 in 118cb3e

installCmd :: BuildOpts -> GlobalOpts -> IO ()

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