Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Conflict between julia and python binaries/artifacts #397

Open
BSchilperoort opened this issue Nov 3, 2023 · 5 comments
Open

Conflict between julia and python binaries/artifacts #397

BSchilperoort opened this issue Nov 3, 2023 · 5 comments
Labels
bug Something isn't working

Comments

@BSchilperoort
Copy link

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.

@BSchilperoort BSchilperoort added the bug Something isn't working label Nov 3, 2023
@cjdoris
Copy link
Collaborator

cjdoris commented Nov 7, 2023

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
Copy link

asinghvi17 commented Aug 29, 2024

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
Copy link

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
Copy link

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

@BSchilperoort
Copy link
Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

4 participants