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

Support Docker integration on Windows #2421

Open
scan opened this issue Jul 30, 2016 · 16 comments · May be fixed by #5315
Open

Support Docker integration on Windows #2421

scan opened this issue Jul 30, 2016 · 16 comments · May be fixed by #5315

Comments

@scan
Copy link

@scan scan commented Jul 30, 2016

I'm trying to get any stack command to work with

docker:
  enabled: true

After enabling docker, stack told me to use the comman stack docker pull, which can through fine and installed the docker image.

From now on, every time I try any stack command, stack quits right away with the message:

System.PosixCompat.User.getEffectiveUserID: not supported: illegal operation

I really want to use Docker here to get a consistent environment. Using stack: Version 1.1.2, Git revision c6dac65e3174dea79df54ce6d56f3e98bc060ecc (3647 commits) x86_64 hpack-0.14.0 on newest Windows 10 Pro, and docker version 1.12.0, build 8eab29e, experimental.

EDIT: I'm pretty sure it is somehow related to this line, but I don't understand enough of it to try and fix it.

@borsboom
Copy link
Contributor

@borsboom borsboom commented Aug 4, 2016

Docker integration does not support Windows at the moment. See https://docs.haskellstack.org/en/stable/docker_integration/#prerequisites and #194.

Since we don't have a specific issue covering Docker support on Windows, I'll rename this one and leave it open. If you'd like to take a stab at adding support, that would be most appreciated. Aside from figuring out how to do user ID mapping on Windows, the code currently assumes that paths from the host can be used exactly in the container, which is not the case for Windows style paths.

@borsboom borsboom changed the title Trying to use docker integration on Windows 10 stops with an error Support Docker integration on Windows Aug 4, 2016
@borsboom
Copy link
Contributor

@borsboom borsboom commented Aug 4, 2016

This seems worth working on now that Docker for Windows is out of beta, which hopefully has decent bind-mounted filesystem performance (unlike Docker Machine, which was basically unusable for anything more than trivial).

@jetaro1
Copy link

@jetaro1 jetaro1 commented Oct 7, 2016

thank you :)

@573
Copy link
Contributor

@573 573 commented Mar 20, 2017

Confirming the issue still exists with Docker Toolbox on Windows 7:

$ MSYS_NO_PATHCONV=1 stack --docker --docker-image=$IMAGE_NAME setup
Downloading Docker-compatible stack executable
Preparing to download stack-1.1.2 ...
Already downloaded.
Running C:\msys64\usr\bin\tar.exe xf C:\Users\me\AppData\Local\Programs\stack\x86_64-linux\stack-1.1.2.tar.gz --strip-components 1 in directory C:\Users\me\AppData\Local\Programs\stack\x86_64-linux\stack-1.1.2\ exited with ExitFailure 128


/usr/bin/tar: Kann nicht mit C verbinden: Aufl▒sung fehlgeschlagen

as @borsboom pointed out:

the code currently assumes that paths from the host can be used exactly in the container, which is not the case for Windows style paths.

@varosi
Copy link

@varosi varosi commented May 31, 2017

hm, I'm playing now with Docker for Windows on Windows 10 (Creators Update) and it seems that this docker is running fpco/stack-build container just well.

@varosi
Copy link

@varosi varosi commented May 31, 2017

I tried a stack based project, but I got this error:

PS D:\Projects\cgraytrace> stack docker pull
Pulling image from registry: 'fpco/stack-build:lts-8.15'
lts-8.15: Pulling from fpco/stack-build
Digest: sha256:60cd13af142c14abc7d4625f6d97611892cfe04b6e0fe908efcf059dfcfe7b9b
Status: Downloaded newer image for fpco/stack-build:lts-8.15
PS D:\Projects\cgraytrace> stack build
InvalidAbsDir "/opt/host/bin"
PS D:\Projects\cgraytrace> stack --version
Version 1.4.1, Git revision ea10057da1b1a49d937e7bcb6f997360bec1f863 (4765 commits) x86_64 hpack-0.17.0
@mgsloan
Copy link
Contributor

@mgsloan mgsloan commented Jun 11, 2017

I bet the problem is that the path parsing assuming the path is for the host platform. Not sure if there's an easy way to fix.

My suggestion would be to open a shell in the docker container and just use that.

@mgsloan mgsloan modified the milestones: P3: Optional, P2: Should Jun 11, 2017
@afraca
Copy link

@afraca afraca commented Aug 29, 2018

Same problem as @varosi .
I know the audience is thin, but this would be quite nice. I "need" to keep Windows as my OS, and developing in 'native' applications (like VS code) is really nice. Up until now I had no problem with just building my project on Windows, but as soon as you touch PCRE you pull your hair out , times 5.

I think I'll just use the fpco docker image, but use a docker volume or something to get something working... But then I won't have a .exe as binary. This is problematic....

@tdaniely
Copy link

@tdaniely tdaniely commented Oct 14, 2018

3 years? docker for windows is way past GA and very stable. Volumes are fully functional & Network is fully functional.
I'm far from proficient in Haskell but after reading through all the issue it seems like the related issues are resolved in docker by now.
Looks like the only real block is in stack code which is simply not platform independent around those bits. If running on windows in docker mode with docker running Linux containers, it should fail for stack-exe: host. And it should not parse that default host path before even evaluating stack-exe.

@borsboom
Copy link
Contributor

@borsboom borsboom commented Oct 20, 2018

@tdaniely A pull request would be welcome!

@jgossage
Copy link

@jgossage jgossage commented Feb 6, 2019

@borsboom It seems that this issue is still live. My understanding is that all the problems resolve around the fact that Stack is not platform independent and Stack has no concept of heterogeneous operating environments as we commonly find using Docker. If my assessment is correct I am prepared to try and create a PR for you.

@borsboom
Copy link
Contributor

@borsboom borsboom commented Feb 6, 2019

Hmm, I'm not sure I'd describe the problem quite that way. The way stack works with Docker is that it re-executes a Linux stack inside the container to perform the build (so the "host" stack really just sets up the environment but everything is done in the container "natively"). The main problem I'm aware of is that stack will try to pass Windows paths to the in-container stack, which of course doesn't work.

I should add that not much work is being on on Stack's Docker support anymore. That said, if this is something you need and are willing to implement and then maintain going forward, then by all means go ahead.

@jgossage
Copy link

@jgossage jgossage commented Feb 6, 2019

@davnn
Copy link

@davnn davnn commented Apr 22, 2020

Any updates on this? Did you work on this @jgossage?

@jgossage
Copy link

@jgossage jgossage commented Apr 22, 2020

gdziadkiewicz added a commit to gdziadkiewicz/stack that referenced this issue Jun 7, 2020
@gdziadkiewicz
Copy link
Contributor

@gdziadkiewicz gdziadkiewicz commented Jun 7, 2020

I'm working on this. With the changes from branch e11adb4 (and version: 2.1.3 in stack.cabal to avoid problems with missing docker image for unreleased version), I was able to run stack --docker ghci on my Windows 10 + Docker for Windows(wsl2 engine) machine. I plan to do more testing before submitting the PR.

It would be great to test it on different configurations, so if any of you are still interested in it, please give it a spin and come back with the results.

gdziadkiewicz added a commit to gdziadkiewicz/stack that referenced this issue Jun 19, 2020
@gdziadkiewicz gdziadkiewicz linked a pull request that will close this issue Jun 21, 2020
2 of 2 tasks complete
gdziadkiewicz added a commit to gdziadkiewicz/stack that referenced this issue Jul 19, 2020
gdziadkiewicz added a commit to gdziadkiewicz/stack that referenced this issue Aug 8, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

You can’t perform that action at this time.