Docker-built binaries should live in a different path

[rrnewton]

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]

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]

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.

[borsboom]

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