Conflict between julia and python binaries/artifacts

[BSchilperoort]

Affects: JuliaCall

Describe the bug
When using a conda/mamba environment and juliacall I encountered an issue when NetCDF files are read by the julia code. When trying to read the files the julia code would raise the following error and crash the kernel:

symbol lookup error: .../.julia/artifacts/*/lib/netcdf.so: undefined symbol: H5Pset_all_coll_metadata_ops

It turns out that this error only occured if python packages depending on netCDF were imported.

For example, the following code would crash:

import esmpy
from juliacall import Main as jl

jl.seval("using NCDatasets")
ds = jl.Dataset("file.nc")

While this runs fine:

from juliacall import Main as jl

jl.seval("using NCDatasets")
ds = jl.Dataset("file.nc")

Workaround:
I managed to avoid this crash by ensuring that the Julia and Python packages used the exact same version of the netcdf5 and hdf5 binaries, in which case things went fine.
However, this can be very challenging to do.

[cjdoris]

Yes this is an unfortunate effect of using the same library installed by two essentially independent package managers.

A few options I can think of:

1. What you currently do - specify exact versions of the libraries.
2. The same, but delegate to a second package such as CondaPkgNetCDFCompat which does nothing except each version specifies a compatible pair of versions of the libraries in Julia and Conda.
3. Modify CondaPkg to handle this for us. There already exists a special (secret) syntax for libstdc++ to ensure it is installed at the same version as ships with Julia. Could have similar ones for HDF5 and NetCDF which find the version of the JLLs installed and insert a corresponding compat for Conda.

[asinghvi17]

I just ran into this issue as well. I wonder if it's possible to have a translation table between JLLs and python packages? Then we can set compat appropriately on the Python end, based on the JLLs in the active Manifest.

I guess this is kind of midway between 2 and 3 though (but without the headache of installing all the extra compat packages)

[felixcremer]

I think we could implement the compat packages as extensions of CondaPkg for the corresponding JLL packages so that they would be imported once CondaPkg and some JLL is loaded together.
We could have a global lookup table with the package name or UUID and the compatible versions that could then be checked in CondaPkg._resolve_find_dependencies

[felixcremer]

@BSchilperoort How did you find the versions that you had to restrict to make NetCDF work from both python and Julia?

[BSchilperoort]

I manually installed the same versions of netCDF4 for python and julia, 1.6.4 for each.

However, in the end we've gone with containerizing the julia numerical model and communicating via a RESTful API instead.

[jkrumbiegel]

@cjdoris we have discussed this issue again in the context of PumasAI/QuartoNotebookRunner.jl#224. I thought that one possibility might be to spin up a separate process in PythonCall (or a shim package) itself so whatever code uses it doesn't have to deal with the process separation by itself. Is that an option you could see being added to PythonCall itself, for example under a Preferences.jl setting so that either you run in double process mode or not?

[cjdoris]

one possibility might be to spin up a separate process in PythonCall

That's not going to happen I'm afraid - PythonCall very much assumes that Python is running in the same process.

One option is to use PythonCall as-is but for you to use Python's multiprocessing to spin up a separate process and do all of your actual work there. Provided you are careful to only load problematic packages in the separate process you should be fine.

Another option is to use PyRun, a highly experimental package I was working on a few years ago which solves this exact problem by running all code in a separate Python process. https://github.com/cjdoris/PyRun.jl