-
-
Notifications
You must be signed in to change notification settings - Fork 9.7k
Migrate build system to PEP 517 #7012
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
Conversation
|
The migration to pyproject.toml in urllib3 was surprisingly easy! We no longer have a setup.py file, and had zero complaints about that. |
|
I'm all for removing setup.py. my worry with hatchling is the bus factor. With setuptools we're at the whim of missing a deprecation warning that no one could reasonably see locally and being broken randomly |
|
I'm all for removing setup.py. my worry with hatchling is the bus factor. With setuptools we're at the whim of missing a deprecation warning that no one could reasonably see locally and being broken randomly. I don't know that the other backends are as widely used or have support for the variety of standards we likely don't need |
|
The beauty of pyproject.toml is that using a different backend is quite easy. setuptools supports dynamic versions too, so there's nothing in this PR that setuptools cannot do. If we were migrating urllib3 to setuptools today, we would probably have stuck to setuptools. (setuptools and hatch builds sdists/wheels differently, so I would check that you have everything you want in those files compared to the existing.) |
|
I'm planning to go with setuptools at this point I think. It's the least overhead and from both of your comments it seems like it has what we need. I'll validate that and push up a finalized version to take out of draft. Thanks for the input! |
26d4b6b to
08f7fe4
Compare
08f7fe4 to
b11f49d
Compare
| name = "requests" | ||
| description = "Python HTTP for Humans." | ||
| readme = "README.md" | ||
| license = {text = "Apache-2.0"} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll note here that we left the text identifier instead of using PEP 639 intentionally. While it is marked for deprecation in Feb 2027, the minimum supported version (setuptools 77) is still quite recent and I'm not comfortable bringing the floor up that high yet. We'll evaluate how this initial migration goes and address that later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It wouldn't be a day ending in y if something in Python Packaging wasn't being deprecated with hard to find warning messages, that's for sure. ;)
This PR follows up on the original announcement of migrating Requests to a PEP 517 compliant backend in 2.33.0. This PR proposes moving to
hatchling which has wide adoption, but there's an argument for staying on setuptoolssetuptools after reviewing our current needs. I'd be curious to hear from other maintainers on if there's a strong preference in either direction based on other projects.@pquentin or @sethmlarson may have input from migrating urllib3 as well. Presumably users with urllib3 2.x are already capable of building with this setup in their environment.