Support Docker integration on Windows

[scan]

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]

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]

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]

thank you :)

[573]

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]

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]

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]

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.

[afraca]

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]

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]

@tdaniely A pull request would be welcome!

[ghost]

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

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.

[ghost]

In that case I will go ahead as I need Haskell woking under Docker on Windows 10 with Ubuntu 18.04 as the target environment for Docker.

…

On Wed, Feb 6, 2019 at 4:24 PM Emanuel Borsboom ***@***.***> wrote: 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. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#2421 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAWTNeD5tzHDZdJhw_v4N2o8NzNHm_Ruks5vK1YygaJpZM4JYzVX> .

[davnn]

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

[ghost]

I have done nothing.

…

On Wed, Apr 22, 2020 at 8:44 AM David Muhr ***@***.***> wrote: Any updates on this? Did you work on this @jgossage <https://github.com/jgossage>? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2421 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACZGNK3K7QL75YLRKJDLD3RN3RBJANCNFSM4CLDGVLQ> .

-- Jonathan Gossage

[gdziadkiewicz]

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.

[alngrd]

Just hit this issue when trying to stack setup on Windows 10 :(

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

Any updates?