bug#54350: Profile collisions in "guix shell"
Hello Guix,
I came across this issue the other day when attempting to create a
profile that could act as a development environment for Guix. In
addition to noting my observations below, I'd like to understand why
there are collisions in a *new* profile tasked with installing the
dependencies of guix? Is this a bug?
The [documentation] notes the below command to start "a new shell where
all the dependencies and appropriate environment variables are set up to
hack on Guix":
#+begin_src sh
guix shell -D guix -CPW
#+end_src
Using guix-shell to export the manifest corresponding to the above one
gets:
#+header: :tangle ./manifest.scm
#+begin_src scheme
;; What follows is a "manifest" equivalent to the command line you gave.
;; You can store it in a file that you may then pass to any 'guix' command
;; that accepts a '--manifest' (or '-m') option.
(package->development-manifest
(specification->package "guix"))
#+end_src
Saving the above to manifest.scm and evaluating the below:
#+begin_src sh
mkdir -p ${GUIX_EXTRA_PROFILES}/guix-build-2
guix package -p ${GUIX_EXTRA_PROFILES}/guix-build-2/guix-build-2 -m
./manifest.scm
#+end_src
Results in the following error:
#+begin_example
...
guix package: error: profile contains conflicting entries for bzip2
guix package: error: first entry: bzip2@1.0.8
/gnu/store/4jkvfh9hp9zf9plrcw490ci6vpvc033d-bzip2-1.0.8
guix package: error: second entry: bzip2@1.0.8
/gnu/store/0ngy7fmrp9g3q35wwccnjxzaaqq9f8wi-bzip2-1.0.8
hint: You cannot have two different versions or variants of `bzip2' in the
same profile.
#+end_example
Adding --allow-collisions to match guix-shell behaviour makes the
installation succeed, as expected.
[documentation]:
--
Suhail
This email is not an offer capable of acceptance, does not evidence an
intention to enter into an agreement, has no operative effect until a
definitive agreement is signed in writing by both parties, and that no
party should act in reliance on the email or any representations of the
sender until a definitive agreement is signed in writing by both
parties.
bug#54350: Profile collisions in "guix shell"
Konrad Hinsen writes: > I run everything that is part of a research project in containers, > meaning "guix shell -C". Related: HPC users on clusters using NFS are also advised to use "guix shell" rather than profiles: https://lists.gnu.org/archive/html/guix-science/2023-12/msg7.html https://lists.gnu.org/archive/html/guix-science/2023-12/msg8.html Cheers, Konrad.
bug#54350: Profile collisions in "guix shell"
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.
