support for matplotlib >=3.11

[xylar]

Proposed new feature or change:

In #1554, matplotlib was constrained to <3.11. This is fine as a temporary fix but prevents anyone wanting to use the latest matplotlib from also using uxarray. This is an issue for E3SM-Unified, which is planning to use the latest matplotlib in its next release.

Is there an effort to relax the constraint?

[rajeeja]

:P I have wanted this pin gone since the day I added it, and cartopy 0.26.0 landing yesterday does fix the matplotlib 3.11 crash, so the mpl side is clear now. The catch is that cartopy 0.26 also stopped emitting lon_0 from PlateCarree and geoviews still reads that key in three places, so on cartopy 0.26 any projected polygon or path plot dies with KeyError: 'lon_0' whether matplotlib is 3.10 or 3.11. I am sending geoviews a patch and will drop the pin behind it, and worth flagging that this hits main already for anyone who picks up cartopy 0.26 today since we never pinned cartopy.

[Sevans711]

@xylar Is your use-case sensitive to the geoviews issues with projection plots and the "lon_0" KeyError? Trying to figure out whether it makes sense to focus on merging #1773 into main ASAP to support this use-case, or to keep the matplotlib<3.11 pin for now and also add new pins for geoviews<=1.15.1 and cartopy<0.26.0, to protect users from this bug (#1780), until the next geoviews release.

If the next geoviews release happens before the next uxarray release and E3SM-Unified release, this would be a non-issue, but it sounds like it might take a couple weeks or longer before the next geoviews release happens.

[xylar]

@Sevans711, we're a giant metapackage but I'm not aware of any of our dependencies running into the geoviews issue you're referring to.

[xylar]

Trying to figure out whether it makes sense to focus on merging #1773 into main ASAP to support this use-case, or to keep the matplotlib<3.11 pin for now and also add new pins for geoviews<=1.15.1 and cartopy<0.26.0, to protect users from this bug (#1780), until the next geoviews release.

The current constraint is quite problematic for us. So I would ask you not to wait.

A side note: The pyproject.toml has various extras, but the conda-forge package is just an omnibus package. It would likely make sense to make a uxarray-base output that doesn't have the dependencies from the viz extras. This would free up those not using viz from uxarray to install whatever matplotlib, cartopy, etc. they need for unrelated viz.

This wouldn't help us, though, because our users likely want the viz part of uxarray.

[Sevans711]

we're a giant metapackage but I'm not aware of any of our dependencies running into the geoviews issue you're referring to.

The current constraint is quite problematic for us. So I would ask you not to wait.

Thank you for the quick reply, this feedback is extremely helpful. Planning to discuss with other uxarray devs during internal meetings and to have a decision soon (hopefully today or tomorrow).

A side note: The pyproject.toml has various extras, but the conda-forge package is just an omnibus package. It would likely make sense to make a uxarray-base output that doesn't have the dependencies from the viz extras. This would free up those not using viz from uxarray to install whatever matplotlib, cartopy, etc. they need for unrelated viz.

This wouldn't help us, though, because our users likely want the viz part of uxarray.

This is a great point as well. Do you know of any users who would use something like this? (Hoping to learn more about how much it should be prioritized.)

[xylar]

This is a great point as well. Do you know of any users who would use something like this? (Hoping to learn more about how much it should be prioritized.)

I think we ourselves would nee to use this option at least during testing because your current matplotlib constraints and your proposed cartopy constraint would leave us unable to proceed with E3SM-Unified testing. I understand the geoviews incompatibility is a problem. For us, the new cartopy is a must-have and the latest matploblib is more or less a must-have as well, as is uxarray itself. So the current state really leaves us in a bind.

[xylar]

I will go ahead and make a draft PR to the conda-forge feedstock to add uarray-base as a slimmed-down output. Then, that draft can be part of the discussion. It'll take a little time.