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.
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
Move project metadata to setup.cfg #1533
Conversation
This comment was marked as off-topic.
This comment was marked as off-topic.
Using Because Shapely 2.0 will break dependent projects like Cartopy, it will be uploaded to Debian experimental first until most of the rdeps have releases which support it. The freeze in preparation for the next stable release is scheduled for February 2023, so not a whole lot of time for rdeps to get their Shapely 2.0 support released. We can keep python-shapely 2.0 in experimental until setuptools 61+ is in unstable and the Shapely rdeps support 2.0, and move it to unstable sometime during the trixie development cycle (after the bookworm release).
Let's ask the maintainer: @doko42, do you plan get setuptools 61+ into bookworm? |
I took a quick look at how it breaks Cartopy, and my hope is that it could be fixed (with some small fixes on both sides, SciTools/cartopy#2076 (comment)). @mwtoews I think this PR is certainly fine for the time being. |
I'm not aware of others at the moment, but the new major version suggests that all rdeps will need changes.
The rdeps in Debian are included in the transition tracker: |
There are actually not that many breaking changes (except for the STRtree interface), assuming the package has been updated for those changes that 1.8 warned about (but yeah, I know that this assumption will not be true in many cases). This are the known breaking changes: https://shapely.readthedocs.io/en/latest/release/2.x.html#breaking-api-changes (although testing cartopy with shapely 2.0 revealed we also broke weakref). (cartopy was actually already updated to fix all the things shapely 1.8 warned about, but was still breaking with shapely 2.0 because it uses some internal shapely APIs)
Thanks, that's useful! Checking those will be interesting to see if we have more (unknown) breaking changes. |
@mwtoews I think this can be undrafted? |
My only hesitation is the timing of shapely 2.0's release (or release candidate) and if setuptools 61+ gets into debian bookworm. This is because I'd rather not unnecessarily move this metadata more than a few times. |
setuptools 65.3.0 is now in unstable, but is prevented from migrating to testing (bookworm) due to breaking rdeps: |
Any update on this effort? It looks like it blocks #1564, so I would like to know if we can move this forward! |
Hi @EwoutH it seems that last week setuptools in debian testing was upgraded, so this PR may not be needed. Update: it builds with debian bookworm (testing), I had made an error before. Thanks @sebastic for tracking development releases! |
@sebastic FYI, shapely 2.0 no longer depends on descartes, so that could be removed as a dependency from https://packages.debian.org/source/experimental/python-shapely |
|
Yes, that was just fixed -> #1591 |
Closing this PR as it's fortunately not needed! It was a close one too! |
This PR is for @sebastic to endorse or say it is not needed, following a recent discussion pyproj4/pyproj#1134 (reply in thread) . This applies only to shapely-2.0, which has been under development for a few years, but will hopefully reach a final release perhaps this year (although no fixed deadline has been formally discussed). Is there an approximate date when setuptools>=61 will be in debian stable?
While modernizing project metadata, I had picked #1426 instead of #1430 considering recent PyPA developments, but forgetting the constraints for binary packaging (i.e. fixed package versions, no pip/network abilities). It is a bit annoying, as I had thought that
pyproject.toml
was the final spot to put project metadata.