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.

Sign up for GitHub

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

Jump to bottom

iris/numpy incomptibility causing notebook issues #294

Closed
w-k-jones opened this issue Jun 6, 2023 · 5 comments
Closed

iris/numpy incomptibility causing notebook issues #294

w-k-jones opened this issue Jun 6, 2023 · 5 comments
Assignees
@w-k-jones
Labels
bug Code that is failing or producing the wrong result dependency Issues with a dependency or import
Milestone
Version 1.5

Comments

@w-k-jones
Copy link
Member

Another annoying dependency issue...

iris v3.6.0 is incompatible with the latest version of numpy (v1.24.3) SciTools/iris#5274

When creating a new environment with mamba, it prioritises numpy v1.24.3 and installs an older version of iris, v3.1.0

This version of iris.load_cube causes an error if given a pathlib.Path object to load, which causes the notebooks to fail

I expect this isn't causing an error in the notebook tests because we use conda to create the environment there, and it probably solves in a different way.

Short term can be fixed by casting the file paths to strings
@JuliaKukulies
Copy link
Member

JuliaKukulies commented Jun 7, 2023 •
edited
Loading

Oh no, how annoying. But great that you figured that out so quickly. I believe we can just go back to strings as these work in any case and any version of iris (and xarray) which probably outweighs the advantages of making use of pathlib.Path objects :)

Are you planning to fix this for v1.5.0 ?

@freemansw1
Copy link
Member

Screaming internally right now. Iris somehow finding a way to irritate me yet again.

It would probably be better to fix this for v1.5, especially since the short-term fix seems reasonable.

As an aside, the other issue raised in the PR around NetCDF incompatibilities that Will raised above will likely cause us (and many other libraries) headaches in the future. I've already experienced some of this with the newer libnetcdf libraries requiring libjpeg-turbo instead of jpeg, which can cause cascading incompatibilities.

@freemansw1 freemansw1 added this to the Version 1.5 milestone Jun 7, 2023
@w-k-jones w-k-jones self-assigned this Jun 7, 2023
@w-k-jones w-k-jones added bug Code that is failing or producing the wrong result dependency Issues with a dependency or import labels Jun 7, 2023
@w-k-jones
Copy link
Member Author

Yes, I resisted the urge to include "long term solution is to yeet iris into the sun" in the original issue...

I'll put together a quick PR this week to fix this, also allows me to fix an issue I found with the changes I made to the requirements files!

The switch to xarray should hopefully cut down our web of dependencies quite a bit and limit these kinds of issues. I'd rather avoid having to start pinning packages in the requirements

@JuliaKukulies
Copy link
Member

Holy moly @freemansw1 NETCDF4 incompabilities are really no joke, I have also experienced some of these. We'll have to keep an eye on this.

Thanks for fixing the strings @w-k-jones !

@w-k-jones w-k-jones mentioned this issue Jun 8, 2023
Merged
11 tasks
@freemansw1
Copy link
Member

Resolved with #295

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@w-k-jones w-k-jones

Labels
bug Code that is failing or producing the wrong result dependency Issues with a dependency or import
Projects
None yet
Milestone
Version 1.5
Development

No branches or pull requests
3 participants
@freemansw1 @w-k-jones @JuliaKukulies