-
-
Notifications
You must be signed in to change notification settings - Fork 87
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
Deprecate the password
setting in favor of token
?
#247
Comments
I don't think we can fully deprecate the |
My thought here was that "token" is a superset of "password," so third-party indices that still use password auth (or any other API cred format besides PyPI's macaroons) can continue to supply passwords, just via the
Does that sound reasonable? I can understand if that's still too disruptive 🙂 |
On one hand, I like the idea of a In general, though, I'm in favor... I think. |
Yeah, probably. The more I think about this the less I'm convinced this would be a net positive change, especially given that the majority of people using this action on PyPI are being nudged towards trusted publishing anyways. So maybe this is worth deferring until a 2.0 version of the action, or similar? |
Fair enough. We can always add a new input and mark the other one as deprecated early, just not remove it for a long time. |
FTR, |
This is a small thing; opening for discussion.
Right now, the action has a
password
setting for users to pass (non-TP) credentials. PyPI and TestPyPI no longer have password-based uploads, however, so this setting's name is arguably confusing for a large number of users who can't/won't switch to Trusted Publishing 🙂So, the proposal: deprecate
password
in favor of a newtoken
or similar setting.password
should have a very long deprecation period, similar to the ones in place for the old underscore settings.For prior art,
twine
also prompts for an API token instead of a password, as of pypa/twine#1040.The text was updated successfully, but these errors were encountered: