Add a mechanism to query keyring for credentials in combination with --no-input

[Darsstar]

What's the problem this feature will solve?

Currently, Pip is conservative and does not query keyring at all when --no-input is used because the keyring might require user interaction such as prompting the user on the console.

Tools such as Pipx and Pipenv use Pip and have their own progress indicator that hides output from the subprocess Pip runs in. They should pass --no-input in my opinion, but Pip should provide some mechanism to still query the keyring in that case. Just not by default. So here we are.

Describe the solution you'd like

A flag to pinky swear that the configured keyring backend does not require any user interaction. It defaults to False, making this opt-in behaviour.

Alternative Solutions

Hardcoding a Personal Access Token in the index url and then probably wondering why things stopped working when it expires.

Additional context

The three UX situations I encountered that would be improved:

• Using: keyrings.google-artifactregistry-auth pipenv update -d fails hard. pipenv#4706 (comment)
  Pipenv passes --no-input when resolving, as of 2020.05.29 if I recall correctly, causing locking to fail. Passing --skip-lock to the install command or using the sync command lets us install from a Pipfile.lock, but to generate/update a Pipfile.lock we need to hardcode credentials in the url the lock command uses.
• pipx install doesn't prompt for credentials for private vcs url pipx#219
  I intend to add a PR for Pipx to pass --no-input but passing --pip-args="--no-input" is a workaround that would work if the feature this issue requests is added.
• Virtualenv's app-data seeder sets PIP_NO_INPUT to a truthy value when it tries to download newer versions.

This is issue for the PR I am working on, for which I need a issue number.

Code of Conduct

• I agree to follow the PSF Code of Conduct.

[uranusjr]

If I understand correctly keyring (the library) does not ask user input on its own, but only shows the user interaction prompt requested by the system? If so, one possible solution would be to add a --force-system-keyring flag that unconditionally enables keyring, and informs the user about the possibilities.

[Darsstar]

@uranusjr

If I understand correctly keyring (the library) does not ask user input on its own, but only shows the user interaction prompt requested by the system?

Incorrect, assuming Pip is not "the system" but the OS is. If the third party keyring is queried (by calling get_password or get_credential for example) the configured backend might require user interaction. It might indeed query the system which could in turn require user interaction via a GUI prompt. Or it could trigger OAuth device flow and output a url + code which needs to be entered in a browser. Or it could do pretty much anything else that require user interaction.
The keyring library does not have an api to request backend to only try getting credentials without requiring interaction, so Pip does not query keyring when --no-input is used to be sure no interaction is required.

If so, one possible solution would be to add a --force-system-keyring flag that unconditionally enables keyring, and informs the user about the possibilities.

#11029 is basically that, but with a different name since I do not currently believe "system" should be a part of the name as I hopefully made clear above. I am not married to the name I chose however.
Also, it does not inform the user that the flag is active.

[Darsstar]

Is there anything I can do, other than wait for more people to look at #11029, to move this along? (There isn't a group I can ping, and pinging random maintainers seems rude. The development documentation for contributing and issue triage didn't give me a clear answer either.)