Add `stack build --prefix` option #848

Open
borsboom opened this Issue Aug 25, 2015 · 15 comments

Comments

Projects
None yet
7 participants
@borsboom
Contributor

borsboom commented Aug 25, 2015

This new stack build option will add a post-build step that rebuilds the targets with a cabal configure --prefix= option in a separate dist directory. This will allow installing packages that use data-files in a fixed location on the file system outside of any stack-controlled sandbox.

@borsboom

This comment has been minimized.

Show comment
Hide comment
@borsboom

borsboom Aug 25, 2015

Contributor

In order to support installation into directories where the user doesn't have write permission (e.g., /usr/local), should support a flag to specify a command to prefix the Setup.hs copy step with (e.g., sudo). Before starting, check whether writing to the destination works, and if it does not, display a friendly error with a suggestion to use the prefixing option.

Contributor

borsboom commented Aug 25, 2015

In order to support installation into directories where the user doesn't have write permission (e.g., /usr/local), should support a flag to specify a command to prefix the Setup.hs copy step with (e.g., sudo). Before starting, check whether writing to the destination works, and if it does not, display a friendly error with a suggestion to use the prefixing option.

@borsboom borsboom changed the title from Add `--prefix` option to Add `stack build --prefix` option Nov 17, 2015

@borsboom

This comment has been minimized.

Show comment
Hide comment
@borsboom

borsboom Nov 25, 2015

Contributor

Make sure this covers the case outlined in #1262 (comment)

Contributor

borsboom commented Nov 25, 2015

Make sure this covers the case outlined in #1262 (comment)

@mgsloan

This comment has been minimized.

Show comment
Hide comment
@mgsloan

mgsloan May 2, 2016

Collaborator

Seems like this issue is cropping up for multiple people. Bumping to P2

Collaborator

mgsloan commented May 2, 2016

Seems like this issue is cropping up for multiple people. Bumping to P2

@mgsloan mgsloan modified the milestones: P2: Should, P3: Optional May 2, 2016

@ilovezfs ilovezfs referenced this issue in Homebrew/homebrew-core May 29, 2016

Closed

haskell-stack: bootstrap stack with stack #1480

@borsboom

This comment has been minimized.

Show comment
Hide comment
@borsboom

borsboom May 29, 2016

Contributor

Important use case for supporting a --prefix option: with it, it would be feasible for Homebrew to build their packages using Stack (for those packages that have a stack.yaml), which would aid reproducibility. See Homebrew/homebrew-core#1480 and Homebrew/legacy-homebrew#49158 for related discussion.

Contributor

borsboom commented May 29, 2016

Important use case for supporting a --prefix option: with it, it would be feasible for Homebrew to build their packages using Stack (for those packages that have a stack.yaml), which would aid reproducibility. See Homebrew/homebrew-core#1480 and Homebrew/legacy-homebrew#49158 for related discussion.

@borsboom

This comment has been minimized.

Show comment
Hide comment
@borsboom

borsboom Jun 1, 2016

Contributor

Here's a more concrete example for Homebrew: Homebrew/homebrew-core#1630

Contributor

borsboom commented Jun 1, 2016

Here's a more concrete example for Homebrew: Homebrew/homebrew-core#1630

@Blaisorblade

This comment has been minimized.

Show comment
Hide comment
@Blaisorblade

Blaisorblade Jul 13, 2016

Collaborator

Further rationale—sorry if already mentioned in some links: clearing snapshots (to recover space) leaves compiled binaries around, but not their data-files.

Collaborator

Blaisorblade commented Jul 13, 2016

Further rationale—sorry if already mentioned in some links: clearing snapshots (to recover space) leaves compiled binaries around, but not their data-files.

@borsboom

This comment has been minimized.

Show comment
Hide comment
@borsboom

borsboom Jul 17, 2016

Contributor

Many packages have data-files that aren't actually required for the package to work (like READMEs and Changelogs), and since this feature would require rebuilding those packages and all packages that depend on them (which could be a lot of packages), it should have a way to skip some or all dependencies.

Contributor

borsboom commented Jul 17, 2016

Many packages have data-files that aren't actually required for the package to work (like READMEs and Changelogs), and since this feature would require rebuilding those packages and all packages that depend on them (which could be a lot of packages), it should have a way to skip some or all dependencies.

@mgsloan

This comment has been minimized.

Show comment
Hide comment
@mgsloan

mgsloan Feb 27, 2017

Collaborator

More demand for this feature, bumping priority.

Collaborator

mgsloan commented Feb 27, 2017

More demand for this feature, bumping priority.

@mgsloan mgsloan modified the milestones: P1: Must, P2: Should Feb 27, 2017

@jgm jgm referenced this issue in jgm/gitit Jun 2, 2017

Open

Cannot build a standalone executable #599

@jgm

This comment has been minimized.

Show comment
Hide comment
@jgm

jgm Jun 4, 2017

I don't understand why this hasn't been fixed by now. It is a serious problem if stack can't be used to install data files to a location outside the stack work directory. Cabal has been able to do this from the beginning. Is there some serious conceptual problem with supporting it for stack?

jgm commented Jun 4, 2017

I don't understand why this hasn't been fixed by now. It is a serious problem if stack can't be used to install data files to a location outside the stack work directory. Cabal has been able to do this from the beginning. Is there some serious conceptual problem with supporting it for stack?

@mgsloan

This comment has been minimized.

Show comment
Hide comment
@mgsloan

mgsloan Aug 6, 2017

Collaborator

@jgm I think the reason this hasn't been resolved is that the data-files mechanism seems pretty clunky. I've never used it, and I don't think most of the stack developers use it.

I have before started on implementing this because folks seem to care about it, but I really didn't like how cludgey it'd be to need to build your package twice just to deal with a change of dist dir:

This new stack build option will add a post-build step that rebuilds the targets with a cabal configure --prefix= option in a separate dist directory.

Perhaps it is possible to instead just do one build with a different dist dir? Any downsides? IIRC there was some issue with using a dist dir that's not under the package dir on windows..

I don't think there is any fundamental difficulty here. It'd be great if someone that wants this feature implemented it.

Collaborator

mgsloan commented Aug 6, 2017

@jgm I think the reason this hasn't been resolved is that the data-files mechanism seems pretty clunky. I've never used it, and I don't think most of the stack developers use it.

I have before started on implementing this because folks seem to care about it, but I really didn't like how cludgey it'd be to need to build your package twice just to deal with a change of dist dir:

This new stack build option will add a post-build step that rebuilds the targets with a cabal configure --prefix= option in a separate dist directory.

Perhaps it is possible to instead just do one build with a different dist dir? Any downsides? IIRC there was some issue with using a dist dir that's not under the package dir on windows..

I don't think there is any fundamental difficulty here. It'd be great if someone that wants this feature implemented it.

@jgm

This comment has been minimized.

Show comment
Hide comment
@jgm

jgm Aug 7, 2017

jgm commented Aug 7, 2017

@evincarofautumn

This comment has been minimized.

Show comment
Hide comment
@evincarofautumn

evincarofautumn Aug 15, 2017

This would be very useful for me as well. My use case is installing a standard library alongside a compiler. stack install puts the compiler executable in ~/.local/bin, but data-files references an absolute path in .stack-work, which may be deleted or changed. It would be very surprising if your compiler installation stopped working because you did a git pull; stack build, causing the old compiler version to reference a newer, possibly incompatible standard library version. I can work around this with Cabal for now, but it’s not ideal for me to have to provide different build instructions for development and installation.

This would be very useful for me as well. My use case is installing a standard library alongside a compiler. stack install puts the compiler executable in ~/.local/bin, but data-files references an absolute path in .stack-work, which may be deleted or changed. It would be very surprising if your compiler installation stopped working because you did a git pull; stack build, causing the old compiler version to reference a newer, possibly incompatible standard library version. I can work around this with Cabal for now, but it’s not ideal for me to have to provide different build instructions for development and installation.

@Rufflewind

This comment has been minimized.

Show comment
Hide comment
@Rufflewind

Rufflewind Sep 14, 2017

Ran into this limitation jgm/gitit#599 while attempting to package gitit in the Arch User Repository. I wasn't able to find another workaround besides switching back to cabal-install.

Ran into this limitation jgm/gitit#599 while attempting to package gitit in the Arch User Repository. I wasn't able to find another workaround besides switching back to cabal-install.

@ilovezfs

This comment has been minimized.

Show comment
Hide comment
@ilovezfs

ilovezfs Mar 18, 2018

@borsboom @mgsloan any updates here? This is still something that would be useful for Homebrew. Some dependency rot made me sad today so I thought I'd ask.

@borsboom @mgsloan any updates here? This is still something that would be useful for Homebrew. Some dependency rot made me sad today so I thought I'd ask.

@mgsloan

This comment has been minimized.

Show comment
Hide comment
@mgsloan

mgsloan Mar 19, 2018

Collaborator

No updates to report. Indeed this issue seems to be a popular request, hopefully it will get addressed. PRs appreciated!

Collaborator

mgsloan commented Mar 19, 2018

No updates to report. Indeed this issue seems to be a popular request, hopefully it will get addressed. PRs appreciated!

@gspe gspe referenced this issue in voidlinux/void-packages May 17, 2018

Open

New Package: xmonad and xmonad-contrib #11741

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