Paul Ganssle @pganssle@qoto.org

@bitecode Also I think it's weird that you would want people to continue to harbor misapprehensions.

It's like saying, "What do end users get out of understanding that in Python variables are names bound to objects rather than objects themselves?"

Even if you don't want to put that in the curriculum for the first day, you definitely wouldn't actively teach them something that's wrong (or strongly implies an incorrect model).

@bitecode I want the end user to populate the values in the [build-system] table. I think they should feel no qualms about doing so any more than they have qualms about filling out `install_requires` in their setup.cfg/.py.

I have personally seen you advocating *against* doing so, based on the misunderstanding that pyproject.toml is some sort of unstable replacement for setup.py.

@bitecode The important part is that the build-system table is the config file *for your build system* and is what people traditionally think of when they mean "pyproject.toml". You don't "switch to pyproject.toml" in that sense because the build-system table is just telling your build tools (tox, pip, etc) how to build your project. It's *required* if you want to switch to anything else, but it's still a *good idea* if you use setuptools: explicit is better than implicit.

@bitecode What worries me is that people don't understand what's going on here and spread misinformation. People say, "Oh I don't want to use pyproject.toml I am happy with setuptools", whereas we, the setuptools maintainers, are desperately trying to get people to declare their build-system metadata.

People are desperately confused about PEP 517 and 518, and about the pyproject.toml file, and this will make it worse.

@bitecode Sorry I meant 621.

@bitecode There's no "weird limbo", just a straight-up misunderstanding that you have been consistently spreading.

One of my main worries about PEP 622 is that it will continue to spread that misunderstanding, because this does *not* make it so that pyproject.toml is an "alternative to setup.py", it just makes it so that there's a standardized format for build backends to use when accepting already-standardized metadata.

It doesn't specify anything about how the builds are done, for example.

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

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

@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 What do you mean by this? The lack of a standard is not blocking anyone storing metadata in pyproject.toml.