I’m especially disturbed to hear this from you, because I thought I was implementing your idea, for your reasons. Specifically:
What I understood in that discussion is that we were on the same page about the problems with requirements: in particular, there are multiple, not very standardized extant ways of scattering information about requirements around the project - some in requirements.txt (not even a standardized filename!) and some in various parts of pyproject.toml.
In turn, people try using pyproject.toml for this because it looks like a natural place for “project” information, where “project” is loosely understood and not formally defined, but might take on some shapes that you identified in that discussion. I understand that you were brainstorming, and that the context was
However, my long-term vision is that we support all those cases, and indeed everything that remotely makes sense, as long as it there is a reasonably elegant way to do it. At least, as long as by “support” we only mean standardizing some config data, so that third parties can make tools.
My long-term fear is that if we don’t do that, people will just abuse [tool] and pretend everything is supported, and there will be a huge mess of repositories x tools that could interoperate but don’t.
So.
The current proposal is exactly my attempt to standardize requirements specifications - not “requirements files”, but explicitly picking up the idea of defining a section in pyproject.toml. My proposed section is called required-to, because I think that makes it read nicely. The keys are descriptions of reasons a given list of requirements would be required (and thereby, all sets of requirements are named). The requirements work in the common existing way that they would in the project.dependencies list or the simple cases in a requirements.txt file - i.e., PEP 508.
It’s abundantly clear to me that people want to make lists of requirements for non-wheel-related reasons; so I talk about some possible kinds of projects (again without trying to define anything formally) because that justifies storing that kind of information inside pyproject.toml. (And it does need to be justified - the entire discussion started from you pointing out that pyproject.toml currently is explicitly wheel-oriented.)
My one concession to “thinking longer term” that’s explicitly in this proposal (and now I realize that it would be fine to sever the idea here and introduce that later) is a [requirements-for] table, where each [requirements-for.<extra-name>] gives lists of tables that are specific to each of the project’s (still an informal concept!) extras.
If the idea came across as any more complicated than that, I guess that’s my fault.