-
Notifications
You must be signed in to change notification settings - Fork 3.3k
Rethink pip's PEP-517 mechanism #9081
Copy link
Copy link
Open
0 / 10 of 1 issue completedLabels
C: PEP 517 impactAffected by PEP 517 processingAffected by PEP 517 processingC: build isolationstate: awaiting PRFeature discussed, PR is neededFeature discussed, PR is neededtype: refactorRefactoring codeRefactoring code
Metadata
Metadata
Assignees
Labels
C: PEP 517 impactAffected by PEP 517 processingAffected by PEP 517 processingC: build isolationstate: awaiting PRFeature discussed, PR is neededFeature discussed, PR is neededtype: refactorRefactoring codeRefactoring code
Fields
Give feedbackNo fields configured for issues without a type.
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/setuptoolsindex page (or some other backend/dependency).Describe the solution you'd like
Stop pip from calling itself to populate build environments.
Once
piphas read thepyproject.tomlfile and a PEP-517 build is needed, it could (thanks to the new resolver):Additional context
We might want to drop the legacy resolver first (or only support this behavior with the new resolver).