Hi everyone, I ran into this issue when I was trying to turn a much-used shell environment into a profile for persisting the binaries in the store. I had been using it for several months, believing it to be OK. Fortunately it was easy to fix.
Background: as part of a reproducible computation workflow (see my talk at the ten-year meeting, https://10years.guix.gnu.org/program/#guix-as-a-tool-for-computational-science), I run everything that is part of a research project in containers, meaning "guix shell -C". Since I rely on Python 2 software, I end up using package transformations frequently to get old software to work. As it turns out now, package transformations are also an excellent way to create profile collisions: three out of five of my commonly used containers have collisions, which I wasn't aware of until a few days ago. >From that perspective, the current behavior of "guix shell" is... let's say "suboptimal". I do understand the motivation, as explained in this thread, but I don't quite understand (1) why profile collisions are so frequent in development environments and (2) why ignoring them in that use case doesn't cause any trouble. When I run "guix shell -D inkscape", I expect to have, as much as possible, the same environment as the one the daemon uses when build inkscape. Does the daemon also switch off collision detection? Cheers, Konrad.
