On Thu, Jun 28, 2018, at 6:27 PM, Brett Cannon wrote:
The file was originally meant to target building wheels for libraries. It just happens that folks have pushed that out to include apps as well. So if the purpose of the file expands to include apps as well then that changes what the PEP should require to be in the file.
It even expanded to include tools not directly related to packaging at all - towncrier was given as an example, and that's a developer tool for producing release notes. I guess we implicitly invited this generalisation by calling it 'pyproject.toml' rather than anything explicitly tied to building or packaging.
I brought this up earlier but towncrier and Black can both be viewed as build tools as they help prepare your library for the final wheel. IOW since they help prep your code release they have a place in the file.
In any case, I think it's too late to say such tools shouldn't use it, and as Nathaniel pointed out, it's pretty surprising that using a tool like towncrier would suddenly change how pip deals with your package. So I think the best option is to say that the presence or absence of pyproject.toml is not significant for build frontends - rather it's the presence of build-system information in that file that matters.
I didn't mean to suggest that tools shouldn't use the file (we added tool namespaces for a reason which you already use 😁). All I'm saying is that originally the goal was for building libraries, which means not specifying build tools didn't really make sense. As I said, if the decision is the community wants to take the file in another direction and we want to open it up for apps as well then taking your suggestion to make the entire build section optional but its existence requires providing all metadata then that seems reasonable.
+Brett