Dev tools like flycheck & flycheck-haskell need the host's TMPDIR and HOME mounted in the docker container

[dysinger]

I'm using emacs (spacemacs with the default 'haskell' & 'syntax-checker' layer in this case) which means flycheck w/ flycheck-haskell. While flycheck-haskell accounts for stack usage, it doesn't work for docker enabled stack projects.

flycheck-haskell expects to run stack --verbosity silent runghc -- .... on 2 files in the host's $HOME/.emacs.d/elpa/flycheck-haskell/ dir. Of course when you run this on a docker project your $HOME/.emacs.d dir is out of sight when stack runs. [I'll work with the flycheck project to fix this in a stack-friendly way that accounts for diving into the stack docker container. Like maybe putting the haskell files it needs in $PROJECT/.stack-work/flycheck-haskell or something.]

flycheck-haskell also expects to write files in the temp dir before running stack. These files also disappear as soon as stack is called & it jumps into the container. Having the host's $TMPDIR mounted as the container's /tmp dir seems useful.

It's a tiny patch. It seems harmless. I've submitted a pull request. This solves part of the problem with flycheck-haskell in a way that's transparent to flycheck-haskell. (I don't have to ask them to change even more things for stack users.)

I do my work on Linux. How can I make the patch better for windows %TEMP_DIR% or Mac (if needed) ?

reference:

• https://github.com/flycheck/flycheck-haskell/blob/master/flycheck-haskell.el#L92
• https://github.com/flycheck/flycheck-haskell/blob/master/flycheck-haskell.el#L70
• https://github.com/flycheck/flycheck-haskell/blob/master/flycheck-haskell.el#L118
• https://github.com/flycheck/flycheck-haskell/blob/master/flycheck-haskell.el#L192

[rrnewton]

Wait, is there any way to turn this new feature off? It seems likely to lead to accidental impurities in docker based builds.

[mgsloan]

It is true that this opens the door to dependence on the user's environment. On the other hand, nothing stack does should be dependent on this. A dependency should only really be added if something is really trying to add it.

So anyway, I don't feel too strongly about adding a flag or not, just not sure how necessary it is.

[rrnewton]

Gosh, it's hard to stay pure. You're right that the stack stuff should be pretty well isolated from home directory builds. I just worry that it compromises other software. However, since the user is basing their stack.yaml off a docker image that is presumably already built in a pure(ish) way (no homedir, no mounts), then they shouldn't really be doing anything but stack builds in this slightly compromised environment, right?

Having the homedir mounted sure is convenient for dropping into the image with stack exec bash. I was surprised to find that it handled a situation where the working copy directory was in my home dir but actually symlink to a different top level dir (/home.local/... vs NFS-mounted home). Nevertheless, it looks like stack managed to handle this gracefully; it mounted both top-level dirs in
this case.