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

@pganssle

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

@pganssle

I undersand that the initial goal of pyproject was not to be a replacement for setup.cfg.

I'm glad that eventually, it will be.

I'm just stating that currently, it IS view mostly as an alternative to setup.cfg, but with no standard support.

Which make it lives in this weird limbo.

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

@pganssle

I assume you don't mean 622, which is pattern matching.

What is the one that is worrying you about?

@bitecode Sorry I meant 621.

@pganssle I don't see what worries you. If fields are standardized, we will have metadata, like dependancies, stored in pyproject instead of setup.cfg/py.

When used tooling to modify metadata, such as when installing packages and hence adding an item to the dependancy list, we will have a common place for that.

It's great.

I know you see those files only from the aspect of building. But many projects use those files without even building anything.

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

@pganssle Can you describe in details the message you wish would be spread instead ?

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

@pganssle Ok, but for the end user, what does it change to see it that way?

What action do you wish they should concretly do differently?

@pganssle And, on the other hand, what bad thing do you worry would happen in practice if they would not be understanding it in that way?

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

@pganssle I see.

There is another side of the story.

Packaging is difficult for most users, not because of lack of tooling, but because it has too many variables. Most users have simple needs.

The 2 files have a lot of overlap, with variants of the overlapping depending of the user tooling. It's just simpler to think "just create a setup.py/cfg, it will do everything you need"'.

Now if suddenly pyproject.toml can contain everything in a standard way, it will make things obvious again.

@bitecode This is wrong: "The two files have a lot of overlap"

What overlap is there, exactly? Currently, the only standardized table in pyproject.toml has *zero overlap* with setup.py (if you don't include setup_requires, which kinda-sorta does something similar to build-system.requires, but is also deprecated and should not be used).

Right now, there's no situation where you would ever be confused as to whether you should specify something in setup.py or pyproject.toml because setuptools doesn't use pyproject.toml for its configuration (in a setuptools project, pyproject.toml is a configuration file for the build front-end — e.g. pip or tox, not the build backend).

@pganssle I understand that the official fields don't overlap, but the end users don't care about [build-system]. For them it's a detail. What they care are the project metadata and where to put them.

Having to care of where depending of the tool, the setup for it to work, the consequences of that and the why of pyproject has no value for the end user. It's like handling memory manually in C VS the GC of Python.

@pganssle The simple answer is just to say: "don't bother, just use this one file. On day, we hope pyproject.toml will replace everything".

This conversation proves it: we need so many message to understand each other, and we are interested in the topic.

It's like when Guido argued that mypy configuration had no reason to be added in setup.cfg because it was an unrelated file. But eventually he had to do it because we asked again and again.

@bitecode Whatever. I do not have time to continue to explain to you what you refuse to understand.

I understand that people are confused by the fact that "pyproject.toml" tends to be a stand-in for both PEP 517/518, and that people seem to think that any addition or use of a pyproject.toml file is the same somehow?

I would urge you to *please* stop making our job harder by giving your ill-informed opinions on packaging and pyproject.toml,