install via mamba failing

[silastittes]

Hi there!

Attempting to install msprime via conda is giving me the following:

Traceback (most recent call last):
  File "/home/stittes/anaconda3/envs/msp/bin/mspms", line 7, in <module>
    from msprime.cli import mspms_main
  File "/home/stittes/anaconda3/envs/msp/lib/python3.10/site-packages/msprime/__init__.py", line 28, in <module>
    from msprime._msprime import (
ImportError: libgsl.so.25: cannot open shared object file: No such file or directory

Attempting to install from the following .yml file

name: msp
channels:
  - conda-forge
dependencies:
  - msprime

Next commands are:

mamba env create -f ~/my_envs/msprime_only.yml
conda activate msp
mspms

Installing instead via pip install msprime works without issue.

Linux distribution details:

No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 18.04.4 LTS
Release:        18.04
Codename:       bionic

[molpopgen]

So this could be due to conda changing which GSL is present, leading to trying to link to the wrong version. To fix that, we need to bump the recipe, forcing a rebuild. A short-term fix for you will be to install msprime via pip. Using pip will solve this problem because the pre-built "wheel" contains the expected version of GSL.

[silastittes]

Easy enough, thanks! Should I close the issue or let someone else close it when the recipe is bumped?

[molpopgen]

I think we should leave it open -- it is nice to have the conda builds actually working.

[jeromekelleher]

Thanks for the report @silastittes, this is helpful. Have we any other conda users that could reproduce this?

[molpopgen]

Trying it now @jeromekelleher in a fresh user account.

[molpopgen]

Worked fine on Pop OS 22.04 with a brand-new miniconda/Py3.9 environment and an env built using the YAML file shown above.

This may be a case of "delete all your conda and install the new miniconda"?

(base) condatester@pop-os:~$ conda activate msp
(msp) condatester@pop-os:~$ which python
/home/condatester/miniconda3/envs/msp/bin/python
(msp) condatester@pop-os:~$ python
Python 3.10.4 | packaged by conda-forge | (main, Mar 24 2022, 17:39:04) [GCC 10.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import msprime
>>> msprime.__file__
'/home/condatester/miniconda3/envs/msp/lib/python3.10/site-packages/msprime/__init__.py'
>>> 

[silastittes]

Interesting! I'll give that a try and reply asap.

[silastittes]

Without reinstalling conda, usingconda env create instead of mamba env create to create the environment worked.

[molpopgen]

Okay, I ignored the mamba thing b/c I'd never heard of it before.

[silastittes]

Mamba is nice as it tends to build environments much faster than conda. First time I've encountered a problem with it. I'll close this as it seems to be entirely a mamba issue.

[silastittes]

Thanks for the help!

[jeromekelleher]

Aha - anyone else hitting issues with mamba? Maybe there's some other magic conda stuff we need to provide so mamba pulls the right GSL?

[molpopgen]

Possibly related:

• Mamba picks very old dependency without a real need mamba-org/mamba#1659
• mamba create fails where conda create succeds mamba-org/mamba#1658

It seems that mamba uses a database to cache dependency information, which is presumably where any speed ups come from. But it looks like things are going wrong occasionally.

[grahamgower]

I mostly use mamba rather than the conda cli when I need a conda environment. One thing to avoid is installing things using both the mamba and conda commands in any single conda environment, as they tend to pull in slightly different versions of dependencies and this can cause breakages.