You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 commentedon Sep 29, 2025
I think this was supposed to fix it? #29745
timhoffm commentedon 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 commentedon 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 commentedon 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 commentedon 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 commentedon 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 commentedon 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 commentedon Oct 9, 2025
There is not a fixed date yet, but I project it will be around end of november.
ksunden commentedon 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+