Skip to content
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

mount $HOME in the container #1951

Merged
merged 1 commit into from
Mar 31, 2016
Merged

mount $HOME in the container #1951

merged 1 commit into from
Mar 31, 2016

Conversation

dysinger
Copy link
Contributor

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

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
@mgsloan
Copy link
Contributor

mgsloan commented Mar 28, 2016

LGTM!

Does this have any potential interactions with the ssh dir mounting stuff? https://github.com/commercialhaskell/stack/blob/mount-home-in-container/src/Stack/Docker.hs#L331 - or perhaps this allows that simplified. Probably not, since inside the container there's also the sandbox home dir.

Will everything that expects things in the homedir use absolute paths? In other words, it seems like ~ will refer to the sandbox home dir, when the tools might expect to find the contents of the home dir that's outside the docker container.

@borsboom Thoughts?

@dysinger
Copy link
Contributor Author

I'll wait for @borsboom's thoughts. Mounting $HOME could cause unexpected probs.

@borsboom
Copy link
Contributor

I think this should work fine with the .ssh mounting -- it means .ssh will be mounted both in the original home directory and in the sandbox-specific home directory. You're right that ~/ paths in the container will refer to the sandbox-specific home directory rather than the host's home directory, but I've thought about this before and it needs to stay this way, as annoying as it is. Otherwise it's just too likely that things like the host's .bashrc will cause problems in the container (especially when the host is running a different OS, like OS X). A possible workaround for that could be to bind-mount specific files (like .bashrc etc.) into the host home directory location, but that might be even more confusing. Worth thinking about doing, but IMO in no way blocks this PR.

@borsboom
Copy link
Contributor

By the way (since you mentioned it elsewhere), this should all work fine for directories with spaces, since the whole argument to -v is passed as a single argument regardless of it containing spaces (it's not parsed, except by docker to find the : separator).

@borsboom borsboom merged commit 0e7c632 into master Mar 31, 2016
@borsboom borsboom deleted the mount-home-in-container branch March 31, 2016 18:30
@gregwebs
Copy link
Contributor

gregwebs commented May 5, 2016

Seems like this would cause a problem if using a container where the user name in the container (home directory actually) is the same as on the host. Should this be checked first?

@mgsloan
Copy link
Contributor

mgsloan commented May 5, 2016

@gregwebs Good point! That seems like it could likely cause problems. I've opened #2108

@borsboom
Copy link
Contributor

borsboom commented May 5, 2016

I'm not sure how much it would cause problems, really. Stack overrides $HOME in the container anyway, so I guess it would only matter if something you're running in Stack needs files that exist in a path in the home directory within the image.

@mgsloan
Copy link
Contributor

mgsloan commented May 7, 2016

@borsboom Does that reasoning also cover the case where the user is named stack?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

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