Keyring support should require an --enable-keyring flag

What’s the problem this feature will solve? Keyring support is enabled silently when the keyring module is installed in the user’s system. There’s no way for the user to say whether or not they want keyring support, or to turn it off when it causes an issue. The pip tests don’t test the behaviour of the keyring module (just the integration) and there have been a number of issues reported which are down to keyring behaviour: #8634, #8485, #8443, #8090

Describe the solution you’d like Add an --enable-keyring flag to pip that acts as an explicit “opt in” to keyring support. Users who want keyring enabled by default can set this via an environment variable or config file.

This would ensure that users have a clear understanding that they are opting into keyring usage, and would ensure that pip’s behaviour can’t be changed by unrelated changes to the user’s system. It would also allow users having issues with keyring to easily disable it (by omitting the flag).

Also, if the user requests keyring support and the module is not available for some reason, it is easy to give an explicit message explaining the issue, whereas at the moment, pip just silently disables the feature with no explanation.

Alternative Solutions Having an option to disable keyring support would allow users to opt out if they hit issues. But it would do nothing to help users to have a clear understanding of when they have keyring support enabled. It also doesn’t address the “silent behaviour change” issue.

Additional context When implemented, keyring support was actively debated, because the approach taken (enabling the feature if a particular package was available) is non-standard. Normally, pip vendors dependencies, and won’t implement features that need modules that don’t conform to its vendoring requirements. The keyring support was merged, but to be honest the concerns about the exception to our vendoring policy (see the thread starting here for details) were never really addressed. In my view, the current issues stem from that, and this issue is an attempt to contain the problem by making it explicitly “opt in”.

[pradyunsg]

I’m strongly in favor of making the keyring support opt-in instead of opt-out.

Nearly all users I’ve interacted with have mentioned how the keyring support in pip is actually surprising rather than useful to them.

[pfmoore]

Good points. Personally, I’d go with:

1. No, it’s global only, and we explicitly don’t support it in requirements.txt. That’s to limit the complexity in general, and because there’s no such support at the moment, so we shouldn’t be adding yet more features as part of this issue, which is all about keeping the impact of keyring support limited.
2. Again, no. There’s no way to disable it now short of uninstalling keyring or using whatever options keyring has to switch it off, why should we add one as part of this change?

For the implementation of this, we would probably want to defer importing keyring at all until we confirm the opt-in.

Probably, but only if it’s easy to do. If it’s complicated, then I’d say defer it to a separate feature request, and leave this as simply switching off the functionality.

(I should probably be clear here, I never actually liked the way the keyring feature was implemented, and if I had my way I’d just rip it out completely. But we’re stuck with it now and my main aim is to limit the damage, and make it easier to not have it affect people who don’t opt into it. I’m particularly offended by #8485 in this regard.)

Also, I should probably have added under Alternative Solutions - Implement a more robust plugin system for pip that allows reliable addition of “optional” features that rely on non-vendored libraries. But that’s easy to say, and much harder to actually do, so I basically just consider keyring support as a demonstration of why such a thing is harder than it looks 🙂