[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#42920: conda 4.8.3 on guix cannot activate environments

From: Ricardo Wurmus
Subject: bug#42920: conda 4.8.3 on guix cannot activate environments
Date: Fri, 21 Aug 2020 05:51:55 +0200
User-agent: mu4e 1.4.10; emacs 26.3

Hugo Buddelmeijer <hugo@buddelmeijer.nl> writes:

> So there are three problems:
> 1. The PATHS in .bashrc should be to ~/.guix-profile/etc/profile.d/, not to
> /gnu/store directly. This is trivial to fix manually.

Perhaps we can replace these locations with
${GUIX_PROFILE:-/gnu/store/…} just as we do in our generated etc/profile

> 2. The prompt is not set correctly, as in, what should happen is that the
> current conda environment is added to the prompt. Instead, the prompt is
> replaced entirely by the environment. This shouldn't be too hard to fix
> manually though.

Weird!  Is this something Conda does wrong because it assumes too much
about the existing prompt?

> 3. The installed software does not have the proper interpreter set. This
> can probably be fixed with patchelf, but now I'm wondering whether this is
> the right approach, because that would be necessary for all packages
> installed through conda. (Or is there a way to do that automatically?
> Apparently just symlinking ld-linux-x86.so.2 into (from?) /lib64 also
> works, but that feels like a very un-guixy hack.)

There’s nothing we can do about this in a general fashion.  Creating a
link from /lib64/ld-linux-x86-64.so.2 to the loader in the glibc package
is indeed what is necessary on Guix System.  If you don’t like to do
this manually, you can use the extra-special-file service.

> Sidenote, FWIW, there are also some problems with some of the scripts
> installed in /gnu/store:
> hugo@alex ~$
> /gnu/store/ihn8dbs84rmc3ai7r1vkvh4cya518wmx-conda-4.8.3/condabin/conda
> -bash:
> /gnu/store/ihn8dbs84rmc3ai7r1vkvh4cya518wmx-conda-4.8.3/condabin/conda:
> /gnu/store/ihn8dbs84rmc3ai7r1vkvh4cya518wmx-conda-4.8.3/bin/python: bad
> interpreter: No such file or directory
> hugo@alex ~$
> /gnu/store/ihn8dbs84rmc3ai7r1vkvh4cya518wmx-conda-4.8.3/bin/activate
> /gnu/store/ihn8dbs84rmc3ai7r1vkvh4cya518wmx-conda-4.8.3/bin/activate: line
> 3:
> /gnu/store/ihn8dbs84rmc3ai7r1vkvh4cya518wmx-conda-4.8.3/bin/.activate-real:
> Permission denied
> /gnu/store/ihn8dbs84rmc3ai7r1vkvh4cya518wmx-conda-4.8.3/bin/activate: line
> 3: exec:
> /gnu/store/ihn8dbs84rmc3ai7r1vkvh4cya518wmx-conda-4.8.3/bin/.activate-real:
> cannot execute: Permission denied
> It seems not necessary to actually use these scripts though.

Would be good to fix them, though.  The activate script may just need a
chmod.  Obviously, the bin/python thing is dead wrong — I must have
missed that instance of prefix confusion that litters the Conda code

> Once we settle on a good way to approach this, where should we document
> this? As in, if we want users to ignore the complaints from conda and
> instead put something in their .bashrc manually, then that information
> should be discoverable somehow.

We shouldn’t need to document this at all; we should patch Conda to do
mostly the right thing.  This involves limiting “conda init” to
user-level changes.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]