You can now inject extra requirements into the isolated Pip PEXes Pex
uses to resolve distributions. The motivating use case for this is to
use the feature Pip 23.1 introduced for forcing --keyring-provider import.
Pex already supported using a combination of the following to force
non-interactive use of the keyring:
A keyring script installation that was on the PATH
A --pip-version 23.1 or newer.
Specifying --use-pip-config to pass --keyring-provider subprocess
to Pip.
You could not force --keyring-provider import though since the Pips
Pex uses are themselves hermetic PEXes without access to extra installed
keyring requirements elsewhere on the system. With
--extra-pip-requirement you can do this with the primary benefit over
--keyring-provider subprocess being that you do not need to add the
username to index URLs. This is ultimately because the keyring CLI
requires username whereas the API does not; but see
https://pip.pypa.io/en/stable/topics/authentication/#keyring-support for
more information.
You can now inject extra requirements into the isolated Pip PEXes Pex uses to resolve distributions. The motivating use case for this is to use the feature Pip 23.1 introduced for forcing
--keyring-provider import.Pex already supported using a combination of the following to force non-interactive use of the keyring:
keyringscript installation that was on thePATH--pip-version23.1 or newer.--use-pip-configto pass--keyring-provider subprocessto Pip.You could not force
--keyring-provider importthough since the Pips Pex uses are themselves hermetic PEXes without access to extra installed keyring requirements elsewhere on the system. With--extra-pip-requirementyou can do this with the primary benefit over--keyring-provider subprocessbeing that you do not need to add the username to index URLs. This is ultimately because the keyring CLI requires username whereas the API does not; but see https://pip.pypa.io/en/stable/topics/authentication/#keyring-support for more information.