unofficial mirror of bug-guix@gnu.org 
 help / color / mirror / code / Atom feed
From: Hugo Buddelmeijer <hugo@buddelmeijer.nl>
To: Ricardo Wurmus <rekado@elephly.net>
Cc: 42920@debbugs.gnu.org
Subject: bug#42920: conda 4.8.3 on guix cannot activate environments
Date: Thu, 20 Aug 2020 18:39:05 +0200	[thread overview]
Message-ID: <CA+Jv8O0g44LWn7_FDHNjRRq61bYYG_AMoYr3BgyHU-_tD_1UCQ@mail.gmail.com> (raw)
In-Reply-To: <87blj7x841.fsf@elephly.net>

[-- Attachment #1: Type: text/plain, Size: 5249 bytes --]

Hi Ricardo,

On Wed, 19 Aug 2020 at 12:07, Ricardo Wurmus <rekado@elephly.net> wrote:

>
> > The conda 4.8.3 package on guix does not seem to work as expected.
>
> Thanks for letting me know.  The upgrade took a long time and required
> quite a bit of patching.
>

Thanks for doing this hard work! It is much appreciated, I don't think I
would have started experimenting with guix without your head start.


> > But activating it does not work properly:
> >
> > hugo@alex ~$ conda activate testenv
> >
> > CommandNotFoundError: Your shell has not been properly configured to use
> > 'conda activate'.
> > To initialize your shell, run
> >
> >     $ conda init <SHELL_NAME>
>
> This is very unfortunate, but perhaps we can work around this.
> Initially I noticed that almost none of the Conda features worked
> without “conda init”, so I decided to run “conda init” as part of the
> build.  This installs a whole bunch of shell initialization files into
> the prefix directory, which — I assume — are meant to be evaluated when
> the shell starts.
>
> So I suspect that you can get around this by manually sourcing the
> appropriate shell init files.  Which of these need to be sourced
> probably depends on your current shell.
>

That indeed kinda works. `conda init bash` adds this to `.bashrc`
(apparently before asking for the sudo password):

# >>> conda initialize >>>
# !! Contents within this block are managed by 'conda init' !!
__conda_setup="$('/gnu/store/ihn8dbs84rmc3ai7r1vkvh4cya518wmx-conda-4.8.3/bin/conda'
'shell.bash' 'hook' 2> /dev/null)"
if [ $? -eq 0 ]; then
    eval "$__conda_setup"
else
    if [ -f
"/gnu/store/ihn8dbs84rmc3ai7r1vkvh4cya518wmx-conda-4.8.3/etc/profile.d/conda.sh"
]; then
        .
"/gnu/store/ihn8dbs84rmc3ai7r1vkvh4cya518wmx-conda-4.8.3/etc/profile.d/conda.sh"
    else
        export
PATH="/gnu/store/ihn8dbs84rmc3ai7r1vkvh4cya518wmx-conda-4.8.3/bin:$PATH"
    fi
fi
unset __conda_setup
# <<< conda initialize <<<

And running this will indeed allow an environment to be activated. The
`testenv3` environment contains only Python:

hugo@alex ~$ which python
which: no python in
(/run/setuid-programs:/home/hugo/.config/guix/current/bin:/home/hugo/.guix-profile/bin:/run/current-system/profile/bin:/run/current-system/profile/sbin)
hugo@alex ~$ source .bashrc
(base) conda activate testenv3
(testenv3)
(testenv3) which python
/home/hugo/.conda/envs/testenv3/bin/python
(testenv3) python
-bash: /home/hugo/.conda/envs/testenv3/bin/python: No such file or directory
(testenv3) readelf --all $(which python) | grep interpreter
      [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]

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.

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.

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

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.

Ultimately it would be nice if all conda packages would be available in
guix directly (as guix packages, removing the need for conda), but that is
going to take a while. The above workarounds are probably sufficient to get
something going until then.

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.

> FWIW, maybe it would be simpler to create a micromamba package than a
> conda
> > package:
> > https://github.com/TheSnakePit/mamba
>
> Why not both?
>

Maybe I'll give it a shot. (micro)mamba is still a bit unstable it seems,
but it might be a good fit for guix.

Cheers,
Hugo

[-- Attachment #2: Type: text/html, Size: 6654 bytes --]

  reply	other threads:[~2020-08-20 17:39 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 [this message]
2020-08-21  3:51     ` Ricardo Wurmus
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=CA+Jv8O0g44LWn7_FDHNjRRq61bYYG_AMoYr3BgyHU-_tD_1UCQ@mail.gmail.com \
    --to=hugo@buddelmeijer.nl \
    --cc=42920@debbugs.gnu.org \
    --cc=rekado@elephly.net \
    /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).