PEP 518: Behavior when pyproject.toml doesn't have build-system.requires

[pradyunsg]

pip/src/pip/_internal/req/req_install.py

Line 450 in 018f03a

return (build_sys.get('requires', ['setuptools', 'wheel']), True)

If other @pypa/pip-committers think it's a good idea, we should not isolate if there's no build-system.requires in the pyproject.toml file.

This isn't something I noticed earlier but maybe this would have eased transitions (prevented issues like the one with pandas). I still think it would be a good idea to do this.

[dstufft]

I think this came up in one of the discussions, and I think the decision was to isolate it anyways, but I don't remember why.

[pradyunsg]

@dstufft #4144 (comment) (and the comments before that)

A quick skim doesn't show any mention/discussion on not isolating when build-system.requires is not specified but a pyproject.toml is present.

[pradyunsg]

@pypa/pip-committers Now that we've seen multiple bug reports about this behaviour, I think pip should be refusing to install packages if the pyproject.toml is not PEP 518 compliant (missing build-system.requires) or to decide on using isolation it on the basis of the presence of build-system.requires, not merely the pyproject.toml file.

The former is sort of pushy, forcing people to use PEP 518 if there's a pyproject.toml file; something I'm fine with personally.

[pfmoore]

@pradyunsg I agree. I'm not 100% clear what use cases there are for a pyproject.toml that doesn't contain build-system.requires - the only one I'm aware of is that I think black uses pyproject.toml for configuration (which is allowed by PEP 518, but only with a compliant pyproject.toml).

If it's just people using the "you can put project config in here" part of PEP 518 without following the full spec, I'm +1 on rejecting pyproject.toml if it doesn't contain the mandatory build-system.requires key. If people want to be able to do this, they should get the PEP updated first.

And yes, it is pushy, but "please conform to the standards we took ages to define, when using a brand new file that never existed before the standard" seems like a perfectly OK point to be pushy on 😄

[pradyunsg]

From #5402 (comment):

Right now, pip opts-in packages to isolation, based on the presence of pyproject.toml but does not require the key to be specified. If it's not there, it just assumes setuptools + wheel are the dependencies and continues with the isolation.

This means that if you have a pyproject.toml, you need that run of pip to also able to install setuptools+wheel; with pip 10.0, it means including wheels for setuptools and wheel, if you're using --no-index.

---

The current behaviour just seems sort of weird to me: the package get opted into isolation because they included configuration for a tool, pip's still sometimes assuming what the build-time requirements are (setuptools+wheel) even in isolation and no one's following the PEP's language.

#5512 makes pip compliant with the PEP's language.

I'm personally fine with making the build-system.requires key optional; updating the PEP and then updating pip as per that. In that case, it's presence should be used as a pointer on whether to enable PEP 518.

@RonnyPfannschmidt has correctly stated that making pip compliant with PEP 518's current language would break existing released versions of various packages invalid.

@asottile is of the opinion that PEP 518 should be updated to allow pyproject.toml files that only hold configuration and no build time requirements.

[RonnyPfannschmidt]

i would like to propose to simply fall back to non-isolated building if the pyproject.toml is incorrect, but warning about it

that way things keep "working" but people see it
additionally pip shoul pick a point in time, at which the warning will turn into an error to follow the pep to the letter

@asottile im wondering, could pyupgrade be thaught to match pyproject.toml and set up correct metadata if its missing, i'd prefer strict standards,

[pfmoore]

I agree with @RonnyPfannschmidt that the pragmatic solution is to warn that pyproject.toml is non-compliant and so we're falling back to the "legacy" (non-isolated) behaviour. But we should warn for one release only, and after that we should start rejecting non-compliant pyproject.toml. It's up to the people wanting to use pyproject.toml without specifying build requirements to get the PEP changed within that timescale (I also prefer that we keep the standards strict).

It really shouldn't be such a huge imposition to ask for the standard to be changed - it's not like the change is massively controversial. If no-one can be bothered to step up to champion that change, I don't see that we should be expected to act as if it had been made.

Personally, I'd prefer that we just assumed the spec was being followed, and triggered build isolation and the new code paths when we saw the new-style config file. But I can see that some projects like the idea of pyproject.toml being "somewhere central for tool config" and from what I can see, some tools (black is the one I found) don't support any other option than pyproject.toml. It would be unfortunate if it's not possible to configure such tools without buying into full PEP 517/518 processing. But on the other hand, being forced into a standards change (one that's quite significant in intent, if not in detail) because of a (probably unintended) grass-roots violation of the agreed spec makes me uncomfortable. The above approach seems like a fair compromise.