Skip to content

Rethink pip's PEP-517 mechanism #9081

@xavfernandez

Description

@xavfernandez

What's the problem this feature will solve?

Currently, to honor PEP-517 and provide an isolated build environment, pip is calling itself.
Which means, spawning a new process (and its complexities), passing over a bunch of options but forgetting some other (and more).
And spawning processes also means that we have to keep track of them via our RequirementTracker.

In addition to those problems, since everything happens in a new process, the in-memory cache isn't shared and every process will reparse /simple/setuptools index page (or some other backend/dependency).

Describe the solution you'd like

Stop pip from calling itself to populate build environments.

Once pip has read the pyproject.toml file and a PEP-517 build is needed, it could (thanks to the new resolver):

  • create a new resolver,
  • resolve this new set of dependencies (while using/conforming to the same options provided by the user and taking advantage of the in-memory cache),
  • install those resolved dependencies in the build environment (possibly building wheels & invoking a new PEP517 process; yes, this will still require a tracker for build dependencies requiring themselves)
  • invoke PEP517 backend in the build environment (like in the "pip calling itself" case)

Additional context

We might want to drop the legacy resolver first (or only support this behavior with the new resolver).

Metadata

Metadata

Assignees

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions