all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Konrad Hinsen <konrad.hinsen@fastmail.net>
To: 54350@debbugs.gnu.org
Subject: bug#54350: Profile collisions in "guix shell"
Date: Tue, 12 Dec 2023 14:10:46 +0100	[thread overview]
Message-ID: <m1jzpjzhux.fsf@fastmail.net> (raw)
In-Reply-To: <afde4231155f7fe32e709dc0d3a4c12d71ea8011.camel@telenet.be>

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.






  parent reply	other threads:[~2023-12-12 13:12 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-12  9:45 bug#54350: Profile collisions are ignored, installing multiple versions of the same package is silently broken Maxime Devos
2022-03-12 14:34 ` Liliana Marie Prikler
2022-03-15 13:50 ` Ludovic Courtès
2022-03-15 15:58   ` Maxime Devos
2022-03-16 10:18     ` Ludovic Courtès
2022-03-16 20:31   ` Greg Hogan
2023-12-12 13:10 ` Konrad Hinsen [this message]
2023-12-15  6:51   ` bug#54350: Profile collisions in "guix shell" Konrad Hinsen
2024-01-16 18:36 ` Suhail

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m1jzpjzhux.fsf@fastmail.net \
    --to=konrad.hinsen@fastmail.net \
    --cc=54350@debbugs.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.