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.