Allow installer users to extend/constrain build dependencies in isolated builds

[jaraco]

What's the problem this feature will solve?

In pypa/setuptools#2893, I made a recommendation to install a plugin or downgrade the build backend to work around an incompatibility with older packages. As Setuptools moves toward adopting distutils and merging its behavior with Setuptools monkeypatches, it's bound to uncover more implicit dependencies on the peculiarities of the implementation. It would be nice, therefore, for the installers to have some control over the build environment, but still to defer the bulk of the behavior to the installer (pip).

In a PEP 517 world with build isolation, it's impossible for the installer to either extend or constrain the dependencies of the build without disabling build isolation, implying also taking on the burden of constructing the build environment, interpreting the requirements, installing them, invoking the build backend, and then tearing down the environment.

In #6144, it was proposed to allow "optional" dependencies in pyproject.toml to address problem, but that proposal is problemmatic for its own challenges, but also doesn't address the above need because it's packager-focused and not installer-focused.

Describe the solution you'd like

I imagine a solution in which pip offers options to extend and constrain build dependencies at install time. Something like:

--build-requires=<dependencies or file:requirements>
--build-constraints=<constraints or file:constraints>

These additional requirements would apply to all builds during the installation. To limit the scope of the specifications, it should also allow for a limited scope:

--build-requires=<project>:<dependencies or file:requirements>
--build-constraints=<project>:<constraints or file:constraints>

For a concrete example, consider a build where setuptools<59 is needed for django-hijack and setuptools_hacks.distutils_workaround is needed for all projects and the deps in scipy-deps.txt is required for mynumpy-proj:

pip install --use-pep517 --build-constraints "django-hijack:setuptools<59" --build-requires "setuptools_hacks.distutils_workaround" --build-requires "mynumpy-proj:file:scipy-deps.txt"

The same specification should be able to be supplied through environment variables.

With these parameters, pip would:

• create the isolated build environments for each of the dependencies.
• install the --build-requires as declared on the command line.
• install the build-requires from the pyproject.toml (or the implied ones if not declared), applying constraints declared on the command-line.
• build the project and tear down as normal.

The requirements declared by the project (in pyproject.toml) would always be honored and a conflict would either raise an error or the project-declared requirements would take precedence.

This isn't a full spec, but a sketch of the idea.

Alternative Solutions

Another approach might be to provide a hook to pip such that after the environment but before and after the build dependencies are installed, a plugin could alter the build environment (preferably with a handle to an "installer" object).

Above where pip installs two sets of build-requires (one from project and one from installer), it could simply merge the two sets of specifications and install those.

Additional context

I believe this proposal belongs with pip and not as a change to the standards as it's an enhancement of pip's implementation and still honors the standards, which have little to say about the UI/tweaks available to customize installation behavior. Please correct me if I'm mistaken.

Code of Conduct

• I agree to follow the PSF Code of Conduct.

[pradyunsg]

Duplicate of #4582. I'll note the suggestions listed here in that issue.