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/
@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.