On Jan 27, 2019, at 3:58 PM, Tzu-ping Chung <email@example.com> wrote:
I guess this depends on how explicit you wan to be. PEP 517 is not enabled unconditionally, only when the project root contains pyproject.toml. The problem is that other projects (unrelated to packaging) take advantage of the file format’s existence, resulting in people “buy in” the situation unknowingly. Things are already explicit from pip’s point of view, but (unanticipated?) third-party usages of the same spec unrelated to PEP 517 muddles the situation
The group of engineers that I work with accidentally encountered PEP-517 by
using pyproject.toml as an alternative to setup.cfg for tool configuration.
In the specific instance it was the black utility but it can happen with any
other utility with similar recommendations.
I agree with pip's view that the presence of pyproject.toml means that you are
*explicitly* announcing compliance with PEP-517. The unexpected part was that
the setuptools build-system shim was incomplete. This will be addressed
shortly if Paul Ganssle has anything to do with it (thanks Paul!). I look at
this failure as a chance to educate other developers on the impact of
introducing something new without understanding the reason for doing so. For
example, if you are already tied to setuptools and using setup.cfg to configure
tools, then introducing a new configuration mechanism for a single tool is
*not* something that should be done lightly.
"There are only two hard things in Computer Science: cache invalidation and naming things." -- Phil Karlton