Move metadata from setup.py to pyproject.toml

[cdce8p]

Note

I explicitly chose to set include-package-data = false to continue to rely on the explicit declaration of package data files. Due to a bug in setuptools, it's not possible (yet) to define package-data for stub packages. (Will be fixed upstream with abravalheri/validate-pyproject#248). If the build folder only contains the stub files + py.typed + METADATA.toml to begin with anyway (i.e. all files should be included in the wheel), it would be enough to just remove package-data completely and rely on include-package-data = true instead (usually the default for pyproject.toml configs). Might be better to tackle that one separately in #160. /CC @Avasam

Setuptools v77.0.3 added support for PEP 639. It requires Python 3.9 which is the current min version, so shouldn't be an issue.

Metadata diff

 ...
-License: Apache-2.0
+License-Expression: Apache-2.0
-Home-page: https://github.com/python/typeshed
+Project-URL: Homepage, https://github.com/python/typeshed
 ...
 Requires-Python: >=3.9
 ...
 License-File: LICENSE
 ...
-Dynamic: classifier
-Dynamic: description
-Dynamic: description-content-type
-Dynamic: home-page
-Dynamic: license
 Dynamic: license-file
-Dynamic: project-url
-Dynamic: requires-dist
-Dynamic: requires-python
-Dynamic: summary
 ...

[srittau]

This is great, thanks!

[hauntsaninja]

Should we switch this to flit_core as well?

I'm worried requiring recent setuptools versions might leave some of our users in a tough position wrt PIP_CONSTRAINT in the event of setuptools back compat issues

[cdce8p]

Should we switch this to flit_core as well?

That probably depends on the package-data here. Is it safe to assume anything in the (temporary) build folder should be included? If yes, it should be possible to change to another build backend.

Regarding the breaking changes though. I don't think this is that big of a problem here. With the move to pyproject.toml, we'd adopt all current config settings without any warnings being shown. The issue being discussed over at setuptools only happened as people haven't seen the warning / didn't fix their configs in over a year and setuptools removed something which isn't supported by other backends to begin with (I believe).

[srittau]

I don't foresee particular compatibility issues. We are providing architecture-independent wheels for all stubs packages. If some users want to build their packages from source nevertheless, I find it fair that they use a fairly recent build tool. I don't want to add an extra build dependency unnecessarily.

[srittau]

https://pypi.org/project/types-pyflakes/

[Avasam]

Should we switch this to flit_core as well?

There's a separate argument to be made to switching to a more lightweight build backend (let's open a new issue or exploratory PR if we wanna discuss that further). In python/typeshed#13622 we went with hatchling.build after strongly considering both it and flit_core.buildapi. Although for something that's published, the extra restrictions/opinions in flit may be fine.

[hauntsaninja]

This wouldn't be an extra dependency, since it would replace setuptools

Happy to do this in another PR though!

Looking at your link, feels like flit would be the best choice here. It's small and fast and has the best compatibility track record out of at least {setuptools, hatchling, poetry}

I agree issues with build backends here will only affect a small minority of users, since most of our uses will use the wheels.

[Avasam]

#166