Running ee_Initialize() can lead to "version 'OPENSSL_3.3.0' not found" when using conda environments

[MatthieuStigler]

When running ee_Initialize() under RStudio (or any R session that uses reticulate), users may encounter an error like:

ImportError: /usr/lib/x86_64-linux-gnu/libcrypto.so.3: version `OPENSSL_3.3.0' not found (required by .../anaconda3/envs/ee/lib/python3.10/lib-dynload/_ssl.cpython-310-x86_64-linux-gnu.so)

This occurs even though the same Python environment and imports work perfectly when run directly in the conda Python REPL.

Cause

This is not specific to rgee itself but results from an interaction between reticulate, conda, and RStudio (or R’s embedding of Python).

When RStudio loads R, it tends to link against the system OpenSSL (/usr/lib/x86_64-linux-gnu/libcrypto.so.3, typically OpenSSL 3.0.x on Ubuntu 24.04).

Meanwhile, the Python interpreter inside the conda environment may have been built against a different OpenSSL version (e.g. 3.3.x).

When reticulate initializes Python, it doesn’t fully “activate” the conda environment’s dynamic library paths (i.e. doesn’t apply what conda activate would do in a shell). As a result, _ssl.cpython-...so from conda tries to link against the system libcrypto.so.3, and symbol version mismatches (e.g. OPENSSL_3.3.0 not found) arise.

This is the same underlying problem described here:

• reticulate issue: rstudio/reticulate#1707
• discussion on OpenSSL mismatch in RStudio: discourse.jupyter.org/t/openssl-mismatch-between-rstudio-and-conda-environments/14123

[MatthieuStigler]

a workaround I found:

Ensure that the OpenSSL version in your conda environment matches the one used by your system (and thus by RStudio).
For Ubuntu 24.04 (OpenSSL 3.0.x), you can fix this by running:

conda activate ee
conda install -c conda-forge "openssl=3.0.*" "ca-certificates"
conda update --all