Unfortunately, this was not backported to 3.10.6. I’ve opened a backport in #30589. Though, I’m not clear whether we’ll do a 3.10.7 since 3.11.0 will be released soon.
In such a case, who would be winning the dependency resolution
matplotlib 3.10.6 with pyparsing 3.3.0 (unbound) or matplotlib 3.10.7 with pyparsing 3.2.x?
i.e. are we sure that a cap on pyparsing would work or could that just push users to the unpinned lower matplotlib versions?
Yeah, that is correct and is what pip/uv would do. I was thinking of communicating with down-stream packaging ecosystems (points to one of the inherent flaws in coupling the packaging meta-data [and build infrastructure] directly into the source).
On conda-forge we can at least patch the meta-data.
We should have upped the dependency earlier, likely for 3.10 - pyparsing 3 was released in 2021. But given the current situation,
I'd rather mildly bumb in a bugfix release than risking running into version concurrency through upper-pinning.
The only other alternative I see would be to ask delaying the pyparsing 3.3 release to after our 3.11 release.
Thanks for jumping on the 3.3.0a1 release! Working kinks out with matplotlib was one of my major goals in putting that out in pypi.
I just pushed out the last pyparsing 3.2.x release last month (September 2025), so I'm not in a super big hurry to put pyparsing 3.3.0 out. I'm happy to hold off until your 3.11 release. Is there a target release date for that version?
Activity
woutdenolf commented on Sep 29, 2025
I think this was supposed to fix it? #29745
timhoffm commented on Sep 29, 2025
Unfortunately, this was not backported to 3.10.6. I’ve opened a backport in #30589. Though, I’m not clear whether we’ll do a 3.10.7 since 3.11.0 will be released soon.
tacaswell commented on Sep 29, 2025
If we are going to put something on the backport branch I would rather put a cap on pyparsing rather than bump the floor.
timhoffm commented on Sep 29, 2025
In such a case, who would be winning the dependency resolution
matplotlib 3.10.6 with pyparsing 3.3.0 (unbound) or matplotlib 3.10.7 with pyparsing 3.2.x?
i.e. are we sure that a cap on pyparsing would work or could that just push users to the unpinned lower matplotlib versions?
tacaswell commented on Sep 29, 2025
Yeah, that is correct and is what pip/uv would do. I was thinking of communicating with down-stream packaging ecosystems (points to one of the inherent flaws in coupling the packaging meta-data [and build infrastructure] directly into the source).
On conda-forge we can at least patch the meta-data.
timhoffm commented on Sep 29, 2025
We should have upped the dependency earlier, likely for 3.10 - pyparsing 3 was released in 2021. But given the current situation,
I'd rather mildly bumb in a bugfix release than risking running into version concurrency through upper-pinning.
The only other alternative I see would be to ask delaying the pyparsing 3.3 release to after our 3.11 release.
ptmcg commented on Oct 9, 2025
Thanks for jumping on the 3.3.0a1 release! Working kinks out with matplotlib was one of my major goals in putting that out in pypi.
I just pushed out the last pyparsing 3.2.x release last month (September 2025), so I'm not in a super big hurry to put pyparsing 3.3.0 out. I'm happy to hold off until your 3.11 release. Is there a target release date for that version?
timhoffm commented on Oct 9, 2025
There is not a fixed date yet, but I project it will be around end of november.
ksunden commented on Oct 9, 2025
@ptmcg We have now released MPL 3.10.7 which updates the pin on pyparsing, so no need to hold off on release on our account.
Modify to highest version number that is safe (matplotlib/matplotlib#…
set matplotlib version to 3.10.7+, set mantid to 6.16.1+