Conda installation fails if conda installs gsl=2.7.1 instead of gsl=2.7

[zatkins2]

I'm not really sure if this is a namaster issue or an issue meant for conda, but I figured I'd document it here in case others ran into it or there was a better solution.

I was trying to build a new conda environment including namaster, but was having issues like the following:

zatkins@della8:~$ python -c "import pymaster"
Traceback (most recent call last):
File "", line 1, in
File "/home/zatkins/.conda/envs/pspy-della8/lib/python3.10/site-packages/pymaster/init.py", line 50, in
from pymaster import nmtlib as lib # noqa
File "/home/zatkins/.conda/envs/pspy-della8/lib/python3.10/site-packages/pymaster/nmtlib.py", line 13, in
import _nmtlib
ImportError: libgsl.so.25: cannot open shared object file: No such file or directory

Indeed, going into my new environment's site-packages folder revealed that library was not linked when generating the _nmtlib .so file:

zatkins@della8:~$ ldd _nmtlib.cpython-310-x86_64-linux-gnu.so
libgsl.so.25 => not found

This was apparently because the gsl version grabbed by conda as a dependency of namaster was gsl 2.7.1, which only contains a copy of libgsl.so.27 (see related issues here and here). Indeed, my conda lib did contain libgsl.so.27 where I guess (conda? namaster?) was expecting libgsl.so.25 to be, and so the linking did not occur.

I wanted a pure conda solution (e.g., not symlinking my libgsl.so.27 to libgsl.so.25). The issue is that the semantic versioning of gsl on the defaults anaconda channel goes 2.7, then 2.7.1, so I think specifying gsl=2.7 in my conda install command still grabs 2.7.1 (vs. if gsl had a 2.7.0 version). Finally, the solution was to enforce gsl is grabbed from the conda-forge channel, which luckily only has gsl 2.7 as the latest version.

The mysteries of when packages are linked to libraries, and by whom, for a conda distribution elude me, but hopefully this helps someone in the future.