python: document python keyring provider#2826
Conversation
Signed-off-by: Jason Hall <jason@chainguard.dev>
✅ Deploy Preview for ornate-narwhal-088216 ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
Just posting this as a WIP while we work out where this should ideally live. Should the recommendation of short-lived credentials go in access.md, with a note that these are only really easily usable for Python today, and the new Python-specific setup instructions go in https://edu.chainguard.dev/chainguard/libraries/python/build-configuration/#authentication ? |
|
I think we should still have them in access.md .. just like .netrc ... In the section in access we link to our docs for using the applicable python tools (pip and whatever else) .. And in the tools (like pip) sections we link out to the access section.. that way all the content can be maintained in one place and found from multiple others. Let me know when this is ready for me to review @imjasonh @angela-zhang |
mosabua
left a comment
There was a problem hiding this comment.
I scheduled to chat tomorrow ..
Signed-off-by: Jason Hall <jason@chainguard.dev>
Signed-off-by: Jason Hall <jason@chainguard.dev>
mosabua
left a comment
There was a problem hiding this comment.
I think we have to explain this all in more detail, especially talking about using this within each project and not attempting it for a global install ..
| To set up the keyring, install the `keyrings-chainguard-libraries` package: | ||
|
|
||
| ```shell | ||
| pip install keyrings-chainguard-libraries |
There was a problem hiding this comment.
I think we have to explain more here or in the project repo for how to use and install
e.g I can only do pip3 install .. but then brew complains .. so how am I really supposed to use it globally .. or should I only use it locally in a venv per project .. so should I add it as dev dependency in each project somehow?
There was a problem hiding this comment.
I also used pip3 install on my local Mac - can we recommend customers install it globally in their existing CI workflow? I imagine each customer will have different environments/setups
There was a problem hiding this comment.
also, here are some similar examples:
https://pypi.org/project/keyrings.codeartifact/
https://pypi.org/project/keyrings.google-artifactregistry-auth/
| Then to use the keyring you can run: | ||
|
|
||
| ```shell | ||
| uv pip install --keyring-provider subprocess \ |
There was a problem hiding this comment.
How would it do that so it does it for every uv build run and for any package?
There was a problem hiding this comment.
I don't know that we can, since uv expects per-project configuration. I'm not a uv expert though, and there may be a way I'm not aware of.
There was a problem hiding this comment.
Well.. how are users to use it then if they just want to run uv build and whatever and not manually install packages..
mosabua
left a comment
There was a problem hiding this comment.
We should still add info for uv that you can use uv build and such after you manually did the pip install .. but in a configured proejct you have to do
uv pip install keyring keyrings-chainguard-libraries --extra-index-url https://pypi.org/simple/
and then you can use uv build from Chainguard Libraries as configured otherwise in the project
| Then to use the keyring you can run: | ||
|
|
||
| ```shell | ||
| uv pip install --keyring-provider subprocess \ |
There was a problem hiding this comment.
Well.. how are users to use it then if they just want to run uv build and whatever and not manually install packages..
Co-authored-by: Manfred Moser <manfred@simpligility.ca> Signed-off-by: Jason Hall <jason@chainguard.dev>
Correct pip command and update usage instructions for keyring.
mosabua
left a comment
There was a problem hiding this comment.
Looks good now. As discussed, if others run into trouble we can amend more in a follow up PR.
[ ] Check if this is a typo or other quick fix and ignore the rest :)
Type of change
Add documentation for Python keyring provider
What should this PR do?
Allow readers to install and use the keyring provider, in environments where that is possible.
Why are we making this change?
We should recommend the use of short-lived credentials wherever possible, and this new release makes it easier for Python users to use these tokens.
What are the acceptance criteria?
How should this PR be tested?
By running the documented commands to pull a private Python package using the keyring provider.