Workaround or Solution for Incompatible openSSL Versions in Python and Julia

[facusapienza21]

Hi!

I had been working in this bug for a long time and I would like to find a workaround this, since I really like PythonCall and I would like to keep using it! Together with @JordiBolibar we raised the points of Inconsistent CondaPkg environments and Julia-Python interface fails in Julia library likely due to wrong SSL credentials in the Julia Discourse, but we still having figure out a workaround this.

I am working with PythonCall to run some python subroutines in the Julia library Sleipnir.jl. We have been using CondaPkg.jl to create the conda environment with the following CondaPkg.tom. This environment results in problems due to inconsistencies in the openSSL version as explained in Inconsistent CondaPkg environments. Looking for alternatives to this, I am still able to create such environment with just conda, so now I am also trying by directly passing the conda path

ENV["JULIA_CONDAPKG_BACKEND"] = "Current"
ENV["JULIA_CONDAPKG_EXE"] = "/path/to/conda"  # optional

I need to work with updated versions of Python packages that right now seems to be installed in my conda environment with version openssl=3.3.2, which is an updated version that the one right now PythonCall requires:
. Downgrading the version of openssl to <3.1 leads to unsolvable environment dependencies.

As @cjdoris commented on Discurse, the long-term solution for this problem will be to update the SSL version, which seems not no be happening until September 2026.

Is there any solution for this? I am really not an expert on how these credentials are used, and barely understand the protocols behind them. However, I do want to make these tools that allow Python-Julia interoperability to work for scientific purposes. I am happy to provide with more information if needed!

[cjdoris]

You can now set JULIA_CONDAPKG_OPENSSL_VERSION=ignore if you'd like to turn off this behaviour. See the README for more info.