Skip to content

Conversation

@nateprewitt
Copy link
Member

@nateprewitt nateprewitt commented Aug 17, 2025

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 setuptools setuptools 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.

@pquentin
Copy link
Contributor

The migration to pyproject.toml in urllib3 was surprisingly easy! We no longer have a setup.py file, and had zero complaints about that.

@sigmavirus24
Copy link
Contributor

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

@sigmavirus24
Copy link
Contributor

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

@pquentin
Copy link
Contributor

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.)

@nateprewitt
Copy link
Member Author

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!

@nateprewitt nateprewitt added this to the 2.33.0 milestone Jan 30, 2026
@nateprewitt nateprewitt changed the title Migrate build system to hatchling Migrate build system to PEP 517 Jan 30, 2026
@nateprewitt nateprewitt marked this pull request as ready for review January 30, 2026 22:45
name = "requests"
description = "Python HTTP for Humans."
readme = "README.md"
license = {text = "Apache-2.0"}
Copy link
Member Author

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.

Copy link
Contributor

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. ;)

@nateprewitt nateprewitt enabled auto-merge (squash) January 31, 2026 02:16
@nateprewitt nateprewitt disabled auto-merge January 31, 2026 02:17
@nateprewitt nateprewitt merged commit cb2c800 into main Jan 31, 2026
70 of 71 checks passed
@nateprewitt nateprewitt deleted the hatchling branch January 31, 2026 02:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants