On 22 June 2018 at 18:01, Brett Cannon <firstname.lastname@example.org> wrote:
> On Fri, 22 Jun 2018 at 09:35 Pradyun Gedam <email@example.com> wrote:
> I think the precise wording is there by not having any wording. ;) If
> 'requires' was meant to be optional then the PEP would have said that.
FWIW, that's my view too.
>> I can think of at least 2 options for behavior when build-system.requires
>> is missing:
>> 1. Consider a missing build-system.requires equivalent to either a missing
>> pyproject.toml or build-system.requires = ["setuptools", "wheel"].
>> 2. Making the build-system table mandatory in pyproject.toml.
>> I personally think (2) would be fine -- "Explicit is better than
> And I think that's what pip's warning is saying the future will be, but they
> aren't quite yet ready to be that strict yet with their users (which I can
Precisely. We currently do accept a missing key, but the presence of
pyproject.toml triggers a user-visible change in behaviour (build
isolation). That is how this question came to light. The current
warning is precisely intended as a deprecation warning that we're
heading towards implementing (2) but we want to give people a chance
The main concern is that tools like towncrier and black *only* allow
configuration to be specified in pyproject.toml, meaning that projects
using those tools are using that file just as a tool config file,
rather than for its stated purpose of build system configuration. IMO,
that's an unfortunate choice that's been made by those tools
(essentially, they have interpreted pyproject.toml as a "common
location for configuration data" rather than a build config file) but
that's their choice.
I view it as Black and Towncrier consider themselves
tools as part of the build process and now helped us push
pyproject.toml faster. :)
Projects can pretty easily address the warning
just by adding
requires = ["setuptools", "wheel"]
to their pyproject.toml (that's what the pip project itself has done).
The only case where this is an issue is where the project
simultaneously needs to avoid the new build isolation mechanism - and
honestly I think that's both a pretty rare situation, and not
something we want to be supporting long-term anyway. I've started
referring to the "no pyproject.toml, no build isolation" behaviour as
the "legacy code path" to emphasise that it's only retained to support
projects that haven't yet moved to the newer standards.
Yeah, fixing the problem is two lines of boilerplate, so hopefully the complains should be minimal.