Configuration of username for index without enabling index

[PeterJCLaw]

What's the problem this feature will solve?

I'm using keyring (with Google's plugin and to access Google Artifact Registry) via subprocess, which unfortunately means that pip doesn't get back a username. Currently this also means that one of pip/keyring prompts for a username as part of pip install --extra-index-url https://private.pypi.example/simple/.

As noted in #11971, this setup currently requires that the username (oauth2accesstoken) be included in the --extra-index-url.

I would like to be able to configure what username should be used (ideally globally) for a given index, without making pip then also enabling that index globally.

I am aware that the username can be specified in the --extra-index-url, however that isn't fully compatible with other tools.

Describe the solution you'd like

It would be great if there was a way to configure what username should be used for a given index without also telling pip to use that index everywhere.

The discussion at #11823 (comment) around a default-key-ring-user option feels like it would work for this case, though I don't feel strongly about that particular approach. (If we did go that way I'd suggest default-keyring-user as the keyring package name is not hyphenated)

Alternative Solutions

I'm semi working around this by setting a username in --extra-index-url https://username@private.pypi.example/simple/, however this doesn't seem to be an expected approach and causes issues for other tools. Notably GitHub Dependabot's config for private PyPIs refuses urls which have a username in them (and in my case I actually need to use a different username for Dependabot anyway) and will thus add the non-username spelling to my requirements files. This workaround therefore only partially works.

Additional context

It looks like #11827 previously discussed this as part of a wider set of changes, though I'm not clear what the status of that is.

It's clear others are hitting similar issues with subprocess keyring which this feels like it would solve -- #11971 for example.

Code of Conduct

• I agree to follow the PSF Code of Conduct.

[webknjaz]

Is using ~/.netrc able to solve your issue?

[PeterJCLaw]

Is using ~/.netrc able to solve your issue?

I haven't found a spelling which lets this work (it was something I tried). I agree that this feels like it would be a good solution if it could work alongside keyring.

For clarity: while ~/.netrc could solve the username portion, storing the password there is not an option -- not least from a security perspective but also because the password in this case is a short-lived token from Google's auth library rather than a persistent value.

From what I can tell, pip is able to use either ~/.netrc or credentials from keyring. The currently is that in pip's keyring handling, if it detects there's no username, then it will prompt the user for that username. Adding the username to the ~/.netrc doesn't appear to work as the username doesn't become available to the logic which is going to query keyring.

Looking in the code:

• in _get_new_credentials, even if both netrc and keyring are allowed there's no passing of information from one to the other -- the only operate independently
• of the two calls to _get_new_credentials only the one from within handle_401 enables keyring and that callsite also explicitly disables netrc

Do you have any insight into why netrc and keyring are kept so separate (despite being right next to each other in the code)?

[webknjaz]

No idea.

[jfly]

IMO, adding more configuration options feels wrong to me, as keyring does have support for retrieving both a password and a username. @PeterJCLaw, would #12748 solve your issue?

[PeterJCLaw]

Yup, #12748 definitely looks like it could help with this, thanks! Agree that's a neater solution overall too.