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

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

Start at ee_Initialize() and trace how reticulate selects and initializes the conda environment under RStudio. Reproduce the OPENSSL_3.3.0 import failure in RStudio and compare it with the working conda Python REPL, then review rstudio/reticulate#1707 for related behavior. The issue does not define a specific fix or test that would establish completion.