Refactor PythonVersionFile global loading#14107
Conversation
| } | ||
| Ok(None) | ||
| fn find_global(options: &DiscoveryOptions<'_>) -> Option<PathBuf> { | ||
| let user_config_dir = user_uv_config_dir()?; |
There was a problem hiding this comment.
I'm not sure why this was passed in previously.
| user_config_working_directory: impl AsRef<Path>, | ||
| options: &DiscoveryOptions<'_>, | ||
| ) -> Result<Option<Self>, std::io::Error> { | ||
| if !options.no_config { |
There was a problem hiding this comment.
We'll respect the no_config logic above instead, which has a message for when it's applied.
| // First, try to find a local version file. | ||
| let local = Self::find_nearest(&working_directory, options); | ||
| if local.is_none() { | ||
| // Log where we searched for the file, if not found |
There was a problem hiding this comment.
These messages are just indented, we don't want to show them when no_local is enabled.
There was a problem hiding this comment.
What do you mean by just indented?
There was a problem hiding this comment.
The code is literally indented, there are no changes otherwise.
|
Example usage in the uv/crates/uv/src/commands/tool/install.rs Lines 77 to 95 in c421cb9 |
| let user_config_dir = user_uv_config_dir()?; | ||
| Self::find_in_directory(&user_config_dir, options) | ||
| .into_iter() | ||
| .find(|path| path.is_file()) |
There was a problem hiding this comment.
Is this last is_file check redundant with the same check done inside find_in_directory?
There was a problem hiding this comment.
Sure seems like it, not sure why that was there — I'll remove it.
| } | ||
| }; | ||
|
|
||
| let version_file = if global { |
There was a problem hiding this comment.
It seems like the previous behavior was that a global pin would only be updated if --global is set, but with the changes in this PR, it gets updated by default if no local pin is found. Is that intended?
There was a problem hiding this comment.
Hm, good point. Confusingly, python_pin_global_use_local_if_available should provide test coverage for this and is passing?
There was a problem hiding this comment.
This is because we only read from this file. For construction of a new file, we use this
uv/crates/uv/src/commands/python/pin.rs
Lines 188 to 200 in 6c5b1e8
There was a problem hiding this comment.
The previous code was just superfluous
There was a problem hiding this comment.
Ah never mind, I was misunderstanding the change to PythonVersionFile::discover. I thought the "fall back to global if nothing local is found" behavior was new, but it's not new.
262fd1a to
b521759
Compare
I was looking into `uv tool` not supporting version files, and noticed this implementation was confusing and skipped handling like a tracing log if `--no-config` excludes selection a file. I've refactored it in preparation for the next change.
While reviewing #14107, @oconnor663 pointed out a bug where we allow `uv python pin --rm` to delete the global pin without the `--global` flag. I think that shouldn't be allowed? I'm not 100% certain though.
While reviewing #14107, @oconnor663 pointed out a bug where we allow `uv python pin --rm` to delete the global pin without the `--global` flag. I think that shouldn't be allowed? I'm not 100% certain though.
While reviewing #14107, @oconnor663 pointed out a bug where we allow `uv python pin --rm` to delete the global pin without the `--global` flag. I think that shouldn't be allowed? I'm not 100% certain though.
While reviewing #14107, @oconnor663 pointed out a bug where we allow `uv python pin --rm` to delete the global pin without the `--global` flag. I think that shouldn't be allowed? I'm not 100% certain though.
While reviewing #14107, @oconnor663 pointed out a bug where we allow `uv python pin --rm` to delete the global pin without the `--global` flag. I think that shouldn't be allowed? I'm not 100% certain though.
While reviewing #14107, @oconnor663 pointed out a bug where we allow `uv python pin --rm` to delete the global pin without the `--global` flag. I think that shouldn't be allowed? I'm not 100% certain though.
While reviewing #14107, @oconnor663 pointed out a bug where we allow `uv python pin --rm` to delete the global pin without the `--global` flag. I think that shouldn't be allowed? I'm not 100% certain though.
While reviewing #14107, @oconnor663 pointed out a bug where we allow `uv python pin --rm` to delete the global pin without the `--global` flag. I think that shouldn't be allowed? I'm not 100% certain though.
While reviewing #14107, @oconnor663 pointed out a bug where we allow `uv python pin --rm` to delete the global pin without the `--global` flag. I think that shouldn't be allowed? I'm not 100% certain though.
I was looking into
uv toolnot supporting version files, and noticed this implementation was confusing and skipped handling like a tracing log if--no-configexcludes selection a file. I've refactored it in preparation for the next change.