From: Ricardo Wurmus <rekado@elephly.net>
To: Hugo Buddelmeijer <hugo@buddelmeijer.nl>
Cc: 42920@debbugs.gnu.org
Subject: bug#42920: conda 4.8.3 on guix cannot activate environments
Date: Fri, 21 Aug 2020 05:51:55 +0200 [thread overview]
Message-ID: <87364gy7tw.fsf@elephly.net> (raw)
In-Reply-To: <CA+Jv8O0g44LWn7_FDHNjRRq61bYYG_AMoYr3BgyHU-_tD_1UCQ@mail.gmail.com>
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
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@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
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
next prev parent reply other threads:[~2020-08-21 3:53 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-18 19:08 bug#42920: conda 4.8.3 on guix cannot activate environments Hugo Buddelmeijer
2020-08-19 10:06 ` Ricardo Wurmus
2020-08-20 16:39 ` Hugo Buddelmeijer
2020-08-21 3:51 ` Ricardo Wurmus [this message]
2020-08-23 19:26 ` Hugo Buddelmeijer
2020-08-25 12:34 ` Ricardo Wurmus
2020-08-25 15:03 ` Hugo Buddelmeijer
2021-03-01 18:50 ` Hugo Buddelmeijer
2021-08-18 10:07 ` Ricardo Wurmus
2022-04-05 10:40 ` zimoun
2022-04-05 13:26 ` Ricardo Wurmus
2022-04-05 14:50 ` Dominic Martinez
2022-04-05 15:19 ` Ricardo Wurmus
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
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87364gy7tw.fsf@elephly.net \
--to=rekado@elephly.net \
--cc=42920@debbugs.gnu.org \
--cc=hugo@buddelmeijer.nl \
/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 public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).