Pip: Document how to disable keyring for users who might want to

Created on 23 Jul 2019  路  21Comments  路  Source: pypa/pip

It'd probably be useful to add something like the following to our documentation. Borrowing from twine:

Disabling Keyring
^^^^^^^^^^^^^^^^^

In some cases, the presence of keyring may be problemmatic. To disable
keyring and defer to a prompt for passwords, uninstall ``keyring``
or if that's not an option, you can also configure keyring to be disabled.

See `twine 338 <https://github.com/pypa/twine/issues/338>`_ for a
discussion on ways to do that.
docs

Most helpful comment

Wait... IMHO No solution proposed here is likeable ! in my case :+1:

1) I want to be able to use pip without having to type a password (to install / uninstall packages etc.) when clearly not necessary
2) I certainly don't want my keyring password to be blank...
3) I have some modules / app that are using "rightfully" the keyring.

Why is not pip asking for the keyring only when required ? (i.e. when using a private repo, for what this feature has been introduced)... And providing a way to bypass the keyring ?

...This feature will just waste 20 minute or so to many developper either not using keyrings or not understanding why pip behaviour changed...

All 21 comments

+1, although I'd prefer it if we documented "how to disable keyring" rather than linking to an ongoing discussion. Let's wait for the discussion to complete and document the conclusions it comes to.

I prefer that too, though I think we can follow up with prose describing the final conclusions later -- it needs someone to convert the discussion there to prose. Until then, linking to the issue is better than doing nothing. :)

Hi, Can i take this up ?

@SharatChandar Sure! We'd probably start by adding the above text to the user guide (the relevant file is in docs/html).

I'll leave it to your judgment to determine where in the file/document, to add this section.

Feel free to mention me if you need any help. :)

@pradyunsg I have a query. Should i document the entire twine discussion or provide a link to the discussion like twine ? Also check this https://github.com/jaraco/keyring/issues/340 and let me know if i should include these.

Documenting the ways to disable would be ideal.

Providing a link to the discussion would work too, but someone would have to come and change that into a discussion later. If you're willing to write a discussion, that'd be great!

The keyring PR seems like a great approach to disable keyring. We should definitely document that.

Keyring in certain cases can prevent the installing of certain packages and modules due to authentication errors. In such cases disabling the keyring is recommended.Keyring can be manually uninstalled but doing so may invalidate other packages that depends on Keyring.

How to disable the keyring
Method 1 :
Set the default keyring password to blank. This will make the keyring accessible without a password.

Method 2 :
keyring could also be disabled by removing the exceute permission from the daemon

@pradyunsg Should i include some other methods too or will this do ?

@SharatChandar You should probably consider cross-platform here. I'm not aware of a keyring "daemon" on Windows (or a service, which would be the equivalent there), so your "Method 2" would make no sense to a Windows user.

@pfmoore Oh Sorry am new to this. I ll keep a cross platform approach going forward.

No problem, no-one can think of all this stuff, that's why it's worth asking for feedback the way you did :-)

@SharatChandar I think we should suggest to users to set environment variable PYTHON_KEYRING_BACKEND to keyring.backends.null.Keyring. That disables keyring (the Python package).

We don't want users disabling the OS keyring password, since that is less secure.

To see more about why I suggest that, see the documentation in the commit that closed https://github.com/jaraco/keyring/issues/340 -- https://github.com/jaraco/keyring/commit/5a887c13c9033951e9a7ac2d356cecc0cd95963.

Python keyring by default is set to null.

keyring can be disabled via command line using '--disable'.

Environments may disable keyring by setting PYTHON_KEYRING_BACKEND to keyring.backends.null.Keyring in the config file.

@pradyunsg these are the methods provided by jaraco to disable keyring. Will it be sufficient to document these ?

Yep yep.

Also, I prefer that you don't address me as "bro".

@pradyunsg Sorry, Didn't mean to offend you. I ll address you formally.

@jaraco Would it be possible to add a section about "how to disable keyring" to keyring's documentation? (see https://github.com/pypa/pip/pull/8019#issuecomment-612646895 for context)

Or is it documented somewhere and I can't find it?

i think instead of adding a documentation for workaround, would be better to make a proper fix, which will make pip calling keyring only if it's needed, not on every install command

Readme now has a section on disabling.

Readme now has a section on disabling.

Since now there is a separate section in keyring docs we can refer back to, where should the link go? I was thinking somewhere in https://pip.pypa.io/en/latest/user_guide/#basic-authentication-credentials might be a good idea. (Since I think that keyring provides you another way to authenticate to pypi)

If that is the case, I can go ahead and create a documentation PR which will add the above link to our docs

Wait... IMHO No solution proposed here is likeable ! in my case :+1:

1) I want to be able to use pip without having to type a password (to install / uninstall packages etc.) when clearly not necessary
2) I certainly don't want my keyring password to be blank...
3) I have some modules / app that are using "rightfully" the keyring.

Why is not pip asking for the keyring only when required ? (i.e. when using a private repo, for what this feature has been introduced)... And providing a way to bypass the keyring ?

...This feature will just waste 20 minute or so to many developper either not using keyrings or not understanding why pip behaviour changed...

See #8687 and #8719.

Was this page helpful?
0 / 5 - 0 ratings