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

Provide an option to configure the location `.stack-work` directory #1178

Closed
Gabriel439 opened this Issue Oct 16, 2015 · 24 comments

Comments

Projects
None yet
9 participants
@Gabriel439

Gabriel439 commented Oct 16, 2015

Right now I'm working on implementing a Haskell plugin for Twitter's build tool, pants, and one thing we'd like to have is the ability to configure the location of the ~/.stack and .stack-work directories under directories managed by the pants tool.

If this is already possible, just let me know, but the last time I checked I couldn't figure out how to do this.

@borsboom

This comment has been minimized.

Contributor

borsboom commented Oct 16, 2015

You can set the STACK_ROOT environment variable to override the location of ~/.stack. .stack-work is not currently overridable.

@borsboom borsboom changed the title from Provide an option to configure the location of `~/.stack` and `.stack-work` directories to Provide an option to configure the location `.stack-work` directory Oct 16, 2015

@borsboom

This comment has been minimized.

Contributor

borsboom commented Oct 16, 2015

I don't think overriding .stack-work would be too hard to implement, and a PR would be welcome.

@borsboom borsboom added this to the P3: Optional milestone Oct 16, 2015

@Gabriel439

This comment has been minimized.

Gabriel439 commented Oct 16, 2015

Thanks for the STACK_ROOT tip! That helps a lot

@feuerbach

This comment has been minimized.

Contributor

feuerbach commented Nov 20, 2015

I would also like to see this implemented.

My use case is that I need to produce two build flavors: with and without hpc. The best way (for incremental compilation) to do this is to build them in two different build trees. I plan to work around this for now by making .stack-work an alternating symlink.

@mrkkrp

This comment has been minimized.

Collaborator

mrkkrp commented Nov 20, 2015

In case nobody is doing this already, I try could to implement the feature (once my current PR is merged). We could make STACK_LOCAL environment variable override .stack-work. If you have alternative ideas in mind, tell me.

@Gabriel439

This comment has been minimized.

Gabriel439 commented Nov 20, 2015

Shouldn't this be passed on the command line? Programming using environment variables is very error-prone: if you make a typo in the environment variable name nothing will catch the error

@mgsloan

This comment has been minimized.

Collaborator

mgsloan commented Nov 21, 2015

@Gabriel439 Good point, this makes more sense as a commandline argument, since it's probably something local to your current build. STACK_ROOT is shared globally, which is why it makes sense to have it as an environment variable.

@mrkkrp Feel free to add this!

mgsloan added a commit that referenced this issue Dec 1, 2015

Merge pull request #1442 from mrkkrp/mrkkrp-configurable-stack-work
Addition of ‘--work-dir’ option to override working directory, #1178
@mrkkrp

This comment has been minimized.

Collaborator

mrkkrp commented Dec 1, 2015

@Gabriel439, @feuerbach, this is solved now. You can add work-dir parameter with relative directory to use instead of .stack-work in stack.yaml or override it on command line via --work-dir=some-directory thing.

Here is the PR: #1442.

@mgsloan, Looks like this may be closed.

@mgsloan

This comment has been minimized.

Collaborator

mgsloan commented Dec 2, 2015

@mrkkrp Thanks for implementing this!

@mgsloan mgsloan closed this Dec 2, 2015

@Gabriel439

This comment has been minimized.

Gabriel439 commented Dec 2, 2015

Thank you! This is fantastic :)

@magthe

This comment has been minimized.

magthe commented Dec 5, 2015

Brilliant!

@abailly

This comment has been minimized.

abailly commented Dec 5, 2015

Thanks for providing this option. Is there a specific why it is not possible to pass an absolute directory?

@mrkkrp

This comment has been minimized.

Collaborator

mrkkrp commented Dec 5, 2015

@abailly, It's mainly because of path package used, which provides type-safe paths. So here we have Path Rel Dir type for this thing. I settled on relative-only paths because it seemed good enough for described use-cases (and default value is certainly a relative path). It's possible though to detect early whether we deal with absolute or relative path and if it's relative, make it absolute and work with absolute paths since then. Although I'm not sure what practical problem it would solve.

@abailly

This comment has been minimized.

abailly commented Dec 5, 2015

Here is a short description of my usage:

  • I have a package which contains sub-packages
  • these packages are built inside a docker container
  • I want to reuse build artifacts across various runs in order to benefit from incremental builds
  • Hence I want to put all produced artifacts into docker volumes and ideally I would like to have to share a single volume
  • I want to isolate the knowledge of where the volume is from the knowledge of where the code lives
  • Hence my idea of providing an absolute path to stack --work-dir, for example through an environment set at docker run or directly when running the container

Plus, supporting both absolute and relative paths seems rather more common than supporting only one type of paths. I can provide a PR if that makes sense to you.

@borsboom

This comment has been minimized.

Contributor

borsboom commented Dec 5, 2015

Another reason it has to be a relative directory is that there is a separate .stack-work for every package in a project, so a single absolute path couldn't work for a multi-package project. It may be possible to move to having a single .stack-work for the whole project, but when we last tried that it triggered a Cabal issue on Windows (I believe Cabal couldn't handle a dist directory outside of the package directory) so we stuck with each package having its own.

@lukexi

This comment has been minimized.

Contributor

lukexi commented Dec 10, 2015

My use case is basically: I have a bunch of packages I'm developing in tandem, where some are libraries and some are applications that depend on the libraries. I'd like to share the build artifacts between them so that changes in library A only have to be rebuilt once, rather than many times for libraries P Q R and applications X Y Z that depend on library A.

So I figured I'd just use the parent directory of packages A-Z for .stack-work, but got:

lukexi@LukeMBP:~/Projects/rumpus$ stack build --work-dir=..
InvalidRelDir ".."

(and of course the same setting it in stack.yaml)
This was a pretty confusing error message since .. is in fact a relative path, no?

@lukexi

This comment has been minimized.

Contributor

lukexi commented Dec 10, 2015

Aha! It looks like my use case is well covered by placing a stack.yaml in the parent directory and using the STACK_YAML environment variable. Great! : )

@wdanilo

This comment has been minimized.

wdanilo commented Feb 25, 2016

I see a very strange behavior here. I'm using --work-dir to specify the .stack-work folder and it actually works but only for the dependencies. The .stack-work is ALSO created in the root of the library I'm building. Is it supposed to be so? Can we affect this bahavior somehow?

@mgsloan

This comment has been minimized.

Collaborator

mgsloan commented Feb 26, 2016

@wdanilo Yes, it's an unfortunate compromise due to cabal or ghc's behavior on windows. It doesn't need to act like this, but we'd need to change some paths and add some special cases for non-windows (and potentially special cases based on cabal / ghc version if it's fixed in newer versions). See the discussion in this issue or #1731 for more info.

Feel free to take on implementation. It hasn't been a priority for us, because it hasn't affected our usage of stack. We'd also prefer to have things behave the same on windows, but directory compatibility is already gone due to the usage of SHAs to keep the dirs shorter to avoid MAX_PATH.

@wdanilo

This comment has been minimized.

wdanilo commented Mar 13, 2016

@mgsloan Thank you for your reply. I doubt I could find now time to implement it, but I would kindly ask you not to close all related issues - I see that both this one as well as #1731 are closed now, but this issue is still unresolved.

@mgsloan

This comment has been minimized.

Collaborator

mgsloan commented Mar 13, 2016

@wdanilo #1731 is not closed. The original goal of this issue was completed.

I kindly ask you to send me alpha software ;)

@wdanilo

This comment has been minimized.

wdanilo commented Mar 13, 2016

@mgsloan: Oh, I'm sorry for the confusion! I've overlooked the #1731 and I just saw the "closed" label next to the reference to this ticket on the bottom, which consequently made me wrongly believe it is closed too.

We will definitively send you the alpha! We haven't released it yet to anybody. I was planning to write an email to you on monday regarding few things, including the alpha :)

@wdanilo

This comment has been minimized.

wdanilo commented Apr 3, 2016

@mgsloan sorry for writing here, but I was not able to catch you any other way - have you seen mails from me? I've sent 2 over the last 3 weeks - regarding the alpha software :)

@mgsloan

This comment has been minimized.

Collaborator

mgsloan commented Apr 5, 2016

@wdanilo Woops sorry about the delay. Looking forward to trying it out!

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