On 30 June 2018 at 06:33, Nick Coghlan <firstname.lastname@example.org> wrote:
> On 28 June 2018 at 11:37, Nathaniel Smith <email@example.com> wrote:
>> So my inclination is to plan on ending up with build-system.requires
>> defaulting to ["setuptools", "wheel"], and build-system.backend
>> defaulting to "setuptools". Hopefully we'll eventually get to a place
>> where ~no-one uses these defaults, but carrying around the code to
>> handle the defaults isn't really a burden.
> While I was going to post to say I liked this approach, after a bit of
> reflection, I realised I prefer Thomas Kluyver's suggestion: instead
> of taking "pyproject.toml" as indicating a build-isolation compatible
> sdist file, instead make "pyproject.toml with a build-system table"
> the marker for that case.
As far as I can see, the only difference this makes is that it means
pip retains the legacy (non-isolated) behaviour in a few more places
(specifically places where it's quite likley the project hasn't
thought about build isolation). So it's basically a slightly more
forgiving version of Nathaniel's proposal.
The part of Nathaniel's approach that I think would be most confusing
is a project that currently uses setup_requires which adds a
pyproject.toml for (say) towncrier. The build would become isolated,
but setup_requires (which is implemented by setuptools, not pip) would
ignore the isolated environment and install in the wrong place (maybe?
I honestly don't know). I'm quite happy to call this deprecated
behaviour and point out that the project should switch to explicitly
using PEP 518, but given that this whole discussion is because people
haven't done that, I suspect Nathaniel's proposal doesn't actually
solve the root issue here...
> If you don't have a build-system table at all, then you'll continue to
> get the legacy sdist handling, allowing the addition of other tool
> config without impacting the way your sdist gets built.
> If you do add a build-system table, then you have to populates the
> "requires" field properly, even if you're using setuptools as your
> build backend.
> That way, the "build-system.backend defaults to setuptools" behaviour
> is only there to support pyproject.toml files that have already opted
> in to build isolation by writing:
> requires = ["setuptools", "wheel"]
That sounds fair to me. In terms of PEP wording:
1. build-system.requires becomes *optional* in pyproject.toml
2. Tools should process projects without pyproject.toml in the same
way as they always have (backward compatibility). For pip, that means
no build isolation, and the old-style processing path.
3. Tools should treat projects with pyproject.toml, but with *no*
build-system.requires key the same way as (2).
4. Tools can assume that no legacy behaviour is needed for projects
that specify pyproject.toml and build-system.requires.
Moving forward to PEP 517, we'd allow a default for
build-system.backend purely as a convenience because PEP 518 was
implemented before PEP 517 - but there's no intention or commitment to
retain *current* PEP 518 code paths once PEP 517 is implemented (i.e,
nobody's suggesting that `build-system.backend missing` should *ever*
be different from `build-system.backend = "setuptools"`).
I do have a question about whether we specifically want the existence of build-system.requires or the existence of the entire build-system section to trigger the fallback behaviour? Is there a situation where any PEP-defined key in that section makes sense without 'requires'? IOW should having a build-system section imply the requirement of build-system.requires and leaving that key out is an error, while leaving the entire section out is now optional and is what triggers the fallback behaviour?
I personally vote to say that if you define build-system you should go all-in and those it's an error to be missing 'requires' in that case.
Specifically Brett made the point that this means that
as a community we're OK with pyproject.toml being the standard
location for tool configuration, and not just for specifying build
tools. I guess I'm personally OK with this (although I do feel that
it's something we didn't fully talk through when writing the PEP, and
we're now getting pushed down this route by circumstance). It might
warrant a change to the PEP title, just to clarify the modified
Yep, the PEP would need a quick once-over to make sure the wording makes sense if this is the final decision, new packaging BDFL. ;)
Nathaniel - are you happy with this variant rather than the one you proposed?
Is someone going to prepare PRs for the PEP and for pip to match this
I can handle any PEP updates once we have settled and the exact change we want.
It sounds important enough that it should probably go into
pip 18.0 (although that's a discussion we can have on the pip tracker
- I'm not sure there's much we need to do, and there may be a PR
PS For completeness, here's the range of options. Shout if I
pyproject.toml build-system.requires Behaviour
-------------- --------------------- -----------------------------
Does not exist N/A Legacy
Exists Does not exist Current: Invalid file (error)
Exists Exists Isolated (full PEP 518)
So I think my suggestion changes this only such that build-system.requires becomes build-system, in which case it's a Thomas/Nathaniel debate, and then having build-system leading to the current behaviour.