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

[Gabriella439]

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]

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

[borsboom]

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

[Gabriella439]

Thanks for the STACK_ROOT tip! That helps a lot

[UnkindPartition]

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]

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.

[Gabriella439]

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]

@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!

[mrkkrp]

@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]

@mrkkrp Thanks for implementing this!

[Gabriella439]

Thank you! This is fantastic :)

[magthe]

Brilliant!

[abailly]

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

[mrkkrp]

@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]

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]

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]

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]

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]

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]

@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]

@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]

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

I kindly ask you to send me alpha software ;)

[wdanilo]

@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]

@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]

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