Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Document the required username #48

Open
PeterJCLaw opened this issue Dec 8, 2023 · 0 comments
Open

Document the required username #48

PeterJCLaw opened this issue Dec 8, 2023 · 0 comments

Comments

@PeterJCLaw
Copy link

PeterJCLaw commented Dec 8, 2023

When using keyring as a library this package's plugin returns the correct username (i.e: oauth2accesstoken), however when using keyring as a CLI tool that value is not printed. I'm guessing that that's just how keyring's CLI works and I'm not suggesting that that's something this project try to change (at least it doesn't feel like a short term or easy solution).

What would be good however is if this project documented the username which is required to be used with the credential which is printed out.

It seems that any username can be specified as the input, which is partly why this can be confusing -- there's nothing to warn the user that they're using the wrong username.

I hit this while trying to use pip's "subprocess" keyring provider (recently added in pypa/pip#11589; documented at https://pip.pypa.io/en/stable/topics/authentication/#using-keyring-as-a-command-line-application), which calls keyring as a CLI. In such cases neither pip nor keyring can know the right username upfront (since they don't know which backend will provide the credential).

It would be great if this project could document that oauth2accesstoken is the right username to use when e.g: constructing urls to GCP hosted PyPI instances so that users who want to use pip & keyring in this way can more easily do so.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant