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

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

Closed
dysinger opened this Issue Mar 25, 2016 · 3 comments

Comments

Projects
None yet
4 participants
@dysinger
Contributor

dysinger commented Mar 25, 2016

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:

dysinger added a commit that referenced this issue Mar 25, 2016

mounts the host's TMPDIR as /tmp in the container
This is for development tools like Emacs flycheck. Some tools expect to
be able to write temp files into /tmp and then run `stack ....` to
process them. Except, without this patch, the /tmp dir files are gone.

resolves #1949
                                                                        |

@dysinger dysinger self-assigned this Mar 25, 2016

dysinger added a commit that referenced this issue Mar 25, 2016

mount $HOME in the container
This patch is for docker projects and specifically to assist tools (e.g.
Emacs) that read/write files in $HOME for dev work (flycheck & friends)

resolves #1949

@dysinger dysinger changed the title from Dev tools like flycheck & flycheck-haskell need the host's TMPDIR mounted in the docker container to Dev tools like flycheck & flycheck-haskell need the host's TMPDIR and HOME mounted in the docker container Mar 26, 2016

@borsboom borsboom removed the in progress label Mar 31, 2016

dysinger added a commit that referenced this issue Apr 6, 2016

mount $HOME in the container
This patch is for docker projects and specifically to assist tools (e.g.
Emacs) that read/write files in $HOME for dev work (flycheck & friends)

resolves #1949

dysinger added a commit that referenced this issue Apr 6, 2016

mount $HOME in the container
This patch is for docker projects and specifically to assist tools (e.g.
Emacs) that read/write files in $HOME for dev work (flycheck & friends)

resolves #1949

borsboom added a commit that referenced this issue Apr 6, 2016

mount $HOME in the container
This patch is for docker projects and specifically to assist tools (e.g.
Emacs) that read/write files in $HOME for dev work (flycheck & friends)

resolves #1949
@rrnewton

This comment has been minimized.

Contributor

rrnewton commented May 6, 2016

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

@mgsloan

This comment has been minimized.

Collaborator

mgsloan commented May 6, 2016

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

This comment has been minimized.

Contributor

rrnewton commented May 7, 2016

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.

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