Add persistent configuration for non-pip APIs
#4294
Conversation
charliermarsh
added
configuration
charliermarsh
force-pushed
the
charlie/configuration
branch
4 times, most recently
from
b9557c0
to
c3ac307
Compare
charliermarsh
force-pushed
the
charlie/configuration
branch
from
c3ac307
to
4df0f77
Compare
charliermarsh
force-pushed
the
charlie/configuration
branch
2 times, most recently
from
59b09d6
to
486ab2f
Compare
| // However, the user-level `tool.uv.pip` settings override the project-level `tool.uv` settings. | ||
| // This is awkward, but we merge the user configuration into the workspace configuration, so | ||
| // the resulting configuration has both `tool.uv.pip.resolution` (from the user configuration) | ||
| // and `tool.uv.resolution` (from the workspace settings), so we choose the former. |
There was a problem hiding this comment.
Not really ideal, I think.
There was a problem hiding this comment.
It's a little awkward but at least it's consistent, maybe we should warn in that case? Are we going to have more complex merging rules for the pip namespace from the user-level config?
charliermarsh
force-pushed
the
charlie/configuration
branch
from
486ab2f
to
cfb022a
Compare
| let client_builder = BaseClientBuilder::new() | ||
| .connectivity(connectivity) | ||
| .native_tls(native_tls) | ||
| .keyring(*keyring_provider); |
There was a problem hiding this comment.
Separate, but I wonder if we should have a Settings::as_client_builder or BaseClientBuilder::from_settings
| let client = RegistryClientBuilder::new(cache.clone()) | ||
| .native_tls(native_tls) | ||
| .connectivity(connectivity) | ||
| .index_urls(index_locations.index_urls()) | ||
| .index_strategy(*index_strategy) | ||
| .keyring(*keyring_provider) | ||
| .markers(markers) | ||
| .platform(venv.interpreter().platform()) | ||
| .platform(interpreter.platform()) | ||
| .build(); |
There was a problem hiding this comment.
Just so it's on your mind as well as mine, I feel like RegistryClientBuilder should take a BaseClientBuilder instead of duplicating the global options? I found this awkward in some places where I needed to construct both types.
There was a problem hiding this comment.
Makes sense, I can look at it at some point.
|
@zanieb - Are you cool with this modulo (1) renaming, and (2) removing the |
I think so! It seems pretty reasonable. |
Add Wire up Split into multiple arguments
charliermarsh
force-pushed
the
charlie/configuration
branch
4 times, most recently
from
3e83554
to
99413a4
Compare
|
Okay, I believe I addressed the biggest feedback. I'm saddened by how much boilerplate will be required to add a new setting in the future. Perhaps we can DRY a lot of this up with macros in the future, but it's not my strength. |
charliermarsh
force-pushed
the
charlie/configuration
branch
from
99413a4
to
16de0ce
Compare
charliermarsh
force-pushed
the
charlie/configuration
branch
from
16de0ce
to
164b8e5
Compare
Summary
This PR introduces top-level configuration for uv, such that you can do:
And
uv pip compile,uv run,uv tool run, etc., will all respect that configuration.The settings that were escalated to the top-level remain on
tool.uv.piptoo, but they're only respected inuv pipcommands. If they're specified in both places, then thepipsettings win out.While making this change, I also wired up some of the global options, like
connectivityandnative_tls, through to all the relevant places.Closes #4250.