GNU bug report logs - #42920
conda 4.8.3 on guix cannot activate environments

Previous Next

Full log

Message #17 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Ricardo Wurmus <rekado <at> elephly.net>
To: Hugo Buddelmeijer <hugo <at> buddelmeijer.nl>
Cc: bug-guix <at> gnu.org, 42920 <at> debbugs.gnu.org
Subject: Re: conda 4.8.3 on guix cannot activate environments
Date: Fri, 21 Aug 2020 05:51:55 +0200

Hugo Buddelmeijer <hugo <at> 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
file.

> 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 <at> 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 <at> 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
base.

> 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.

-- 
Ricardo

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.