RT @McSinyx@twitter.com
Thank you @brettsky@twitter.com, @di_codes@twitter.com, @pganssle@twitter.com, @pf_moore@twitter.com, @pradyunsg@twitter.com, @SDisPater@twitter.com, @takluyver@twitter.com, @uranusjr@twitter.com and others for rolling out a saner standard for metadata. Finally a way to specify multiple maintainers! https://www.python.org/dev/peps/pep-0621/
If this PEP621 is finalized, we will finally be able to use pyproject.toml as a complete alternative to setup.cfg/py. This and PEP 582 are badly needed changes to the python packaging ecosystem and can't come soon enough.
@bitecode What do you mean by this? The lack of a standard is not blocking anyone storing metadata in pyproject.toml.
@pganssle No, but everybody is using their own proprietary fields, so it's like having a different file for each system. In which case, no point of having pyproject, setup.cfg works out of the box and fetch __version__ automatically.
@bitecode That doesn't make sense. This doesn't change anything about the capabilities of setuptools, and there will still be "proprietary fields".
Your one example of fetching __version__ automatically (which, notably, setuptools doesn't do by default) isn't even possible in the spec as written, and would require falling back to a "proprietary field".
@bitecode The concept of "pyproject.toml as an alternative to setup.cfg/setup.py" is also really a problem, because it makes it seem like the two things are fundamentally different.
In reality — regardless of whether PEP 622 passes — we'll write a tool that takes `setup.cfg` and translates it into equivalent fields of `pyproject.toml`. Using `pyproject.toml` to store setuptools' configuration will add no capabilities, the only difference will be that you'll be able to keep your build configuration in a different file using a different format.
This makes a lot of sense from a practical point of view:
- setup.cfg works with setuptools, which is here if you have pip, no need for another tool. And it has goodies.
- pyproject requires intalling another tool, and you need to change it if you change tooling
So why bother with pyproject at all?
But if pyproject becomes standard, then it will be adopted everywhere, and will be the path of least resistence.
@bitecode There are a lot of misconceptions there, hard to unpack them all.
I think the problem you are having is a category error. pyproject.toml is a TOML file that anyone can use for their configuration. Even with no standard, setuptools was planning to move configuration into there anyway because INI files are under-specified and don't have real types.
@bitecode The only situation where "Why bother with pyproject at all?" makes sense is if you think "using pyproject.toml" means "using a backend other than setuptools that puts its configuration in pyproject.toml".
But your arguments have *nothing to do with pyproject.toml*. Other backends could put their configuration in setup.cfg or in build.py or anywhere.
@bitecode We are migrating the *entire ecosystem* to use PEP 517 and PEP 518 *by default* (no matter what you specify), so "you have to install another tool if you use pyproject.toml" makes no sense. You use pyproject.toml to declare what build system you are using and pip just handles it for you.
"Why bother with pyproject at all"? doesn't make sense — you still need to declare you build system metadata even if you're just using setuptools, it's just done implicitly in some situations.