Support credentials from environment variables. #6723
Conversation
Use PIP_USERNAME and PIP_PASSWORD for authentication if both are defined in env.
- Fix line length failing py27 test.
|
Is it not possible to use keyring to do this? The upcoming version of pip will have support for keyring. |
|
That would complicate our setup. Most other tools which we use, incl.
twine, reads credentials from the env. We have automated that setup.
The change i simple and has been requested by orhers as well.
…On Thu, 18 Jul 2019, 04:07 Pradyun Gedam, ***@***.***> wrote:
Is it not possible to use keyring to do this? The upcoming version of pip
will have support for keyring.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#6723?email_source=notifications&email_token=AAMCZSIZWORPDDMSIO4Z5NDP77F67A5CNFSM4IEVQYD2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2HDFXY#issuecomment-512635615>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAMCZSLJRXOQH4TT6PTVD73P77F67ANCNFSM4IEVQYDQ>
.
|
|
For #4789 (as indicated in news file). |
|
Ah, good catch @chrahunt! I updated OP so that merging this PR will auto-close that issue. :D @lhupfeldt -- While I don't know yet if we're going to merge this or not, thanks for for filing this PR! It's moving us forward on a long standing issue and is much appreciated. :) |
|
This means that the specified A good side of having included keyring support means that you could now easily write a |
|
My use case is a proxy repo requiring credentials. There will only be one
index. I think this is common scenario.
Having to write a package seriously complicates this otherwise very simple
use case. First you have to write the package, but then you also have to
somehow pre-install this package on all systems using pip, since obviously
you cannot use pip to install it.
My patch is really simple and I think it would benefit a lot of user with
servers without direct internet access.
The point about multiple indexes should be documented though.
I'm on holiday and won't be able to provide any updates for a week.
I hope you will accept the PR for the next release.
…On Sun, 21 Jul 2019, 00:35 Xavier Fernandez, ***@***.***> wrote:
This means that the specified PIP_USERNAME & PIP_PASSWORD would be sent
to all indexes (compared to netrc & keyring solutions that match on the
url).
A good side of having included keyring support means that you could now
easily write a pip-env-credentials package (or some other name) defining
a new keyring backend
<https://pypi.org/project/keyring/#write-your-own-keyring-backend>
reading those env variables and once this package installed, pip would
honor those env variables.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#6723?email_source=notifications&email_token=AAMCZSIJRWPPZ2XW425COUDQAOHLJA5CNFSM4IEVQYD2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2NXGIY#issuecomment-513504035>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAMCZSKJCIXXEOML7NV4ZCDQAOHLJANCNFSM4IEVQYDQ>
.
|
- Documantation: Add note about same credentials used for all indexes.
|
I have updated the documentation to mention that the same credentials will be used for all indexes. |
|
What are your thoughts on including this in the next release? I think this is really the simplest way of integrating with CI servers, while at the same time the complexity of the added code is extremely low. |
|
twine also supports keyring. I understand that the need for this but it is already possible to get equivalent (or superior) functionality, while requiring less functionality in pip. It should be doable to have a keyring backend that reads from environment variables. We worked on the keyring integration and one of the primary motivators for me supporting that work, was the fact that pip no longer has to do additional work to support different authentication workflows -- the end users can setup a keyring backend using whichever mechanism they prefer and pip knows how to use it. |
|
Oh, I don't love the GitHub mobile UI. 🙃 |
|
I don't really have much stake in this, but I agree with @pradyunsg - this is definitely something I'd have hoped the keyring integration would have covered, and if it doesn't I'd rather we addressed the deficiencies in that integration, rather than adding a second way of doing this. If the problem is the bootstrapping issue that you can't use keyring until you've installed it, then that was something explicitly discussed when the support was added. Unless there's something new here that wasn't considered in that discussion, I don't see the point in having the same debate again. |
|
Sorry, I'm not aware of what previous discussions you have had about this.
If I understand correctly you expect me to:
1) Install the python keyring package on my systems (without using pip)
2) Implement my own keyring backend and install that on my systems (without
using pip)
3) Configure keyring to on all my systems to use my special backend.
While I understand the desire to keep pip simple, I really feel that the
expectation that users should do the above instead of adding the few lines
of code to pip to read env vars will be a severe stumbling block for using
pip non-interactively in a DevOps environment. This is probably why twine
supports env vars (like a lot of other tools do) in addition to keyring.
As a side note I don't think gnome-keyring can run in a non-privileged
container.
Don't get me wrong, keyring support is great, but I think mostly beneficial
for interactive use.
…On Fri, 2 Aug 2019, 07:58 Paul Moore, ***@***.***> wrote:
I don't really have much stake in this, but I agree with @pradyunsg
<https://github.com/pradyunsg> - this is definitely something I'd have
hoped the keyring integration would have covered, and if it doesn't I'd
rather we addressed the deficiencies in that integration, rather than
adding a second way of doing this.
If the problem is the bootstrapping issue that you can't use keyring until
you've installed it, then that was something explicitly discussed when the
support was added. Unless there's something new here that wasn't considered
in that discussion, I don't see the point in having the same debate again.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#6723?email_source=notifications&email_token=AAMCZSKYG7ZZQBMIK6R5ANDQCPEHJA5CNFSM4IEVQYD2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3MWDWI#issuecomment-517562841>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAMCZSMMJL4NYEXEWJUCFE3QCPEHJANCNFSM4IEVQYDQ>
.
|
|
Hello! I am an automated bot and I have noticed that this pull request is not currently able to be merged. If you are able to either merge the |
|
|
||
| with caplog.at_level(logging.DEBUG): | ||
| auth = MultiDomainBasicAuth() | ||
| get = functools.partial( |
There was a problem hiding this comment.
I would just call auth._get_new_credentials directly and store the result in an intermediate variable. If this ever fails the assertion output looks better as well since it would be retrieved_credentials == ('foo', 'bar') which is a bit easier to understand than get, IMO.
| env_username = os.environ.get(user_var) | ||
| env_password = os.environ.get(passwd_var) | ||
| if env_username: | ||
| if env_password: |
There was a problem hiding this comment.
I would not put this restriction - there were many people in #6796 that have authentication consisting of a single token.
|
I'm gonna close this PR due to the merge conflicts, a lack of activity and because we have a open tracking issue for this request. Thanks for filing this PR @lhupfeldt and feel free to file a new one if/when you fix the merge conflicts. :) |
|
I was under the impression that the idea was turned down. |
lock
bot
added
the
auto-locked
|
Well, because I'm looking at this discussion again today, and I noticed that you've said:
You can use There is no additional configuration to be done -- keyring will pick up that backend, assuming you have set the approreiate metadata. That said, let's continue the discussion in the motivating issue for this, to establish if there's still interest. |
Use PIP_USERNAME and PIP_PASSWORD for authentication if both are
defined in env.
Closes #4789.