JuliaPy / JuliaPy/PythonCall.jl
Conflict between julia and python binaries/artifacts
- Dominant language
- Julia
- Stars
- 1.1k
- Forks
- 86
- Avg merge
- 1d 22h
- Merged PRs (30d)
- 3
Description
**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:
```sh
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:
```py
import esmpy
from juliacall import Main as jl
jl.seval("using NCDatasets")
ds = jl.Dataset("file.nc")
```
While this runs fine:
```py
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.
Contributor guide
No contributing guide indexed for this repository
Research direction
Start by reproducing the two Python examples involving esmpy, juliacall, NCDatasets, and file.nc, then compare the loaded netcdf and hdf5 binaries. Trace where the Julia and Python environments select conflicting artifacts. Done means the demonstrated import order no longer crashes with the undefined H5Pset_all_coll_metadata_ops symbol.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- julia, python
- Domain
- backend
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 35/100