conda fails to run activate scripts, resulting in incorrect paths

[cboettig]

The following python script fails to run in a conda-based environment:

import rioxarray
rioxarray.open_rasterio("https://data.source.coop/cboettig/carbon/cogs/irrecoverable_c_total_2018.tif")

Throwing the error:

 reticulate::source_python("py-test.py")
Error in py_run_file_impl(file, local, convert) : 
  ImportError: /usr/lib/x86_64-linux-gnu/libssl.so.3: version `OPENSSL_3.2.0' not found (required by /home/rstudio/.local/share/r-miniconda/envs/r-reticulate/lib/python3.10/site-packages/rasterio/../../.././libcurl.so.4)
Run `reticulate::py_last_error()` for details.

Note carefully the import path listed, ImportError: /usr/lib/x86_64-linux-gnu/libssl.so.3: . This is not the correct path for a conda environment, conda does not link the system library, and the correct path should be within the parent Conda environment, not the system.

This error can be reproduced in pure python from the bash terminal if we call a conda environment from PATH without doing the conda activate step (or in a base env, conda init and source ~/.bashrc ). As I understand it, packages like this one (or those it depends on) have activation hooks that must be set to link libraries appropriately, and it appears that reticulate isn't doing this when working with conda?

[adisarid]

Encountering the same issue, it seems to me that this issue is also related to multiple issues that were reported in the past, like:

• reticulate ssl import error
• Openssl mismatch between RStudio and conda environments
• and perhaps even this one though not directly related to reticulate and reported in the rstudio repo

According to these sources, you have accurately identified the issue, being that rstudio is affecting reticulate to pick up the system openssl version instead of the conda openssl version.

Until this is a resolved, a suggest workaround would be to create a virtual env instead of a conda environment, i.e., reticulate::virtualenv_install.

[cboettig]

Thanks @adisarid . For some more context you might find this helpful: https://docs.conda.io/projects/conda-build/en/latest/resources/activate-scripts.html . As you have noted, activation scripts are an optional feature used by some conda packages. Running the activation scripts the way conda expects should probably resolve this and may avoid unintended consequences of some of the suggestions listed in these threads (like LD_LIBPRARY_PATH, which sound like they could impact the behavior of non-conda packages that should be linking against system libraries instead of the conda ones).

e.g. for the above, I think this happens because https://github.com/conda-forge/gdal-feedstock/blob/main/recipe/scripts/activate.sh is not run. This would normally happen by activating conda, which I think means sourcing https://github.com/conda-forge/gdal-feedstock/blob/main/recipe/build.sh#L102. I think this is what reticulate should be doing when the user sets a conda env, instead of just altering PATH, but I haven't tracked through all the details here.

At very least it might be worth mentioning in the docs conda is going to be only partially supported. I'm well aware of virtual envs as well, but in many contexts that is not going to be a viable alternative.