unofficial mirror of bug-guix@gnu.org 
 help / color / mirror / code / Atom feed
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




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