Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
uv
has support for keyrings, as long as the option is--keyring-provider=subprocess
. But this isn't exposed in therye
CLI.Some things I haven't addressed, happy to discuss:
I haven't implemented it for piptools. I expect it's possible, in fact more features could be implemented using pip-compile's
--pip-args
argument, but I think the plan is to move touv
as the default going forward, so I don't know how much desire there is to extend the piptools backend. But if it's needed, I can do it, either in this PR or as followup work.In practice, I'd expect that people would want to always pass this
--keyring-provider
value for all calls, and it does pollute the code a bit, passing round the CLI options. I think another way to go could be to put it in the global config and/or the project TOML, and just read it from there. (I'd actually prefer this interface for my own uses.) But I wanted to stay close to the existing CLI ofuv
andpip
, so stuck with that interface. Again, happy to iterate.Test
From a
rye init
project: