Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Stack install should take a --path option #342

Closed
drwebb opened this issue Jun 17, 2015 · 21 comments
Closed

Stack install should take a --path option #342

drwebb opened this issue Jun 17, 2015 · 21 comments
Assignees
Milestone

Comments

@drwebb
Copy link
Contributor

@drwebb drwebb commented Jun 17, 2015

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.

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

@cdepillabout
Copy link
Member

@cdepillabout cdepillabout commented Jun 18, 2015

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

@snoyberg snoyberg added this to the 0.2.0.0 milestone Jun 18, 2015
@gregwebs
Copy link
Contributor

@gregwebs gregwebs commented Jun 18, 2015

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
Copy link
Contributor

@snoyberg snoyberg commented Jun 18, 2015

See the discussion in #153

@chreekat
Copy link
Contributor

@chreekat chreekat commented Jun 18, 2015

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

@bitemyapp
Copy link
Contributor

@bitemyapp bitemyapp commented Jun 18, 2015

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

@chreekat
Copy link
Contributor

@chreekat chreekat commented Jun 18, 2015

@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
Copy link
Contributor

@gregwebs gregwebs commented Jun 18, 2015

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

@snoyberg
Copy link
Contributor

@snoyberg snoyberg commented Jun 18, 2015

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
Copy link
Contributor

@chreekat chreekat commented Jun 18, 2015

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
Copy link
Contributor

@bitemyapp bitemyapp commented Jun 18, 2015

@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
Copy link
Contributor Author

@drwebb drwebb commented Jun 19, 2015

@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
Copy link
Contributor

@snoyberg snoyberg commented Jun 19, 2015

Neither. It should only apply to the install command.

@drwebb drwebb added the in progress label Jun 21, 2015
@drwebb
Copy link
Contributor Author

@drwebb drwebb commented Jun 21, 2015

@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
Copy link
Contributor

@snoyberg snoyberg commented Jun 21, 2015

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

@leahneukirchen
Copy link

@leahneukirchen leahneukirchen commented Jun 26, 2015

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
Copy link

@zimbatm zimbatm commented Jul 7, 2015

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
Copy link
Contributor

@radix radix commented Jul 7, 2015

@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
Copy link

@zimbatm zimbatm commented Jul 7, 2015

@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
Copy link
Contributor

@radix radix commented Jul 7, 2015

@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
Copy link

@leahneukirchen leahneukirchen commented Jul 7, 2015

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

@drwebb
Copy link
Contributor Author

@drwebb drwebb commented Jul 11, 2015

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

@drwebb drwebb closed this Jul 11, 2015
@snoyberg snoyberg removed the in progress label Jul 11, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

9 participants
You can’t perform that action at this time.