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

Docker-built binaries should live in a different path #911

Closed
rrnewton opened this Issue Sep 3, 2015 · 3 comments

Comments

Projects
None yet
4 participants
@rrnewton
Contributor

rrnewton commented Sep 3, 2015

In the same sense that we separate binaries based on architecture, shouldn't we separate them based on whether they are built by a docker image?

When I built my first docker-based executable, it landed in a directory like this:

Linking .stack-work/dist/x86_64-linux/Cabal-1.18.1.5/build/docker-hello-world/docker-hello-world ...
.stack-work/install/x86_64-linux/lts-2.22/7.8.4.20141229/bin/
Installing executable(s) in
/tmp/docker_hello_world/.stack-work/install/x86_64-linux/lts-2.22/7.8.4.20141229/bin

This happens to be a different directory than if I build without docker, but only because the GHC version happens to be 7.8.4.20141229.

The above path doesn't give an indication that it was built for docker and in fact may not run at all on the host platform! (It may depend on dynamic libraries inside the docker image the selected, right?) And in principle the GHC version used in the docker build could be the same as in the non-docker build causing these two different kinds of files to collide, no?

@rvion

This comment has been minimized.

Contributor

rvion commented Sep 3, 2015

that's also what I understood, but I may be wrong.
if it really is the case, I'm also +1 on having binaries in separate folders

@borsboom

This comment has been minimized.

Contributor

borsboom commented Sep 3, 2015

Is this something you've experienced difficulty with? In most cases, the binaries should be compatible since the directory they go into is based on the GHC bindist, so if your host system needs libgmp.so.3 but the Docker image uses libgmp.so.10, they'll end up in different directories (a -gmp4 suffix for the former). I've been able to switch between Docker/non-Docker with success in the past, although it's been a while since I tried that.

That said, what you suggest makes sense. Would have to think on exactly how to construct the directory, though. Using like the Docker image ID wouldn't be great because then if you switch to a slightly different Docker image (say, an extra layer that adds a distro package) you don't want it to throw out everything it's built already. Perhaps a label value can be attached to images that'll be used as part of the path, that way image creators can control it.

@snoyberg snoyberg added this to the Docker milestone Sep 6, 2015

@borsboom borsboom modified the milestones: Docker, P2 Sep 12, 2015

@borsboom borsboom modified the milestones: P1: Must, P2: Should Nov 19, 2015

@borsboom borsboom self-assigned this Nov 19, 2015

@borsboom

This comment has been minimized.

Contributor

borsboom commented Nov 21, 2015

This should also ensure that ~/.stack/setup-exe-cache binaries are not shared (as reported in #1367).

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