Conversation
|
Note for reviewers: The added code is nearly an exact copy paste from |
|
I should almost certainly add some new tests for this... |
|
Some new sample outputs ...it occurs to me that
|
|
Can you add a test for the pathological but motivating case where a registry package depends on the bumped package, causing a conflict if not updated? So that we cover why we need the full set of resolver-installer options. |
charliermarsh
left a comment
There was a problem hiding this comment.
This looks great! The one thing that's missing is a few tests to verify that the lockfile is actually getting updated.
|
Any plans to merge this fix? |
bd5a0a1 to
af44ca6
Compare
| // Try to find the package of interest in the lock, falling back to the root if unsure | ||
| let package = if let Some(name) = &name { | ||
| lock.packages() | ||
| .iter() | ||
| .find(|package| package.name() == name) | ||
| } else { | ||
| lock.root() | ||
| }; |
There was a problem hiding this comment.
This logic for mapping the package to the version is extremely dubious to me...
| let pyproject_path = project.root().join("pyproject.toml"); | ||
| let name = project | ||
| .pyproject_toml() | ||
| .project | ||
| .as_ref() | ||
| .map(|project| project.name.clone()); |
There was a problem hiding this comment.
this is how we get the "name" we'll be looking up in the lockfile
There was a problem hiding this comment.
I think this part can at least be simplified to project.project_name()
| // Find the project in the workspace. | ||
| // No workspace caching since `uv version` changes the workspace definition. | ||
| let project = if let Some(package) = package { | ||
| VirtualProject::Project( | ||
| Workspace::discover( | ||
| project_dir, | ||
| &DiscoveryOptions::default(), | ||
| &WorkspaceCache::default(), | ||
| ) | ||
| .await? | ||
| .with_current_project(package.clone()) | ||
| .with_context(|| format!("Package `{package}` not found in workspace"))?, | ||
| ) | ||
| } else { | ||
| VirtualProject::discover( | ||
| project_dir, | ||
| &DiscoveryOptions::default(), | ||
| &WorkspaceCache::default(), | ||
| ) | ||
| .await? | ||
| }; |
There was a problem hiding this comment.
This is how we find the project we use to lookup the pyproject.toml to get the name from
|
|
||
| /// Find the pyproject.toml we're modifying | ||
| /// | ||
| /// Note that `uv version` never needs to support PEP723 scripts, as those are unversioned. |
There was a problem hiding this comment.
Nit: This is the proper style
| /// Note that `uv version` never needs to support PEP723 scripts, as those are unversioned. | |
| /// Note that `uv version` never needs to support PEP 723 scripts, as those are unversioned. |
| )?; | ||
|
|
||
| let pyproject_path = project.root().join("pyproject.toml"); | ||
| let name = project.project_name().cloned(); |
There was a problem hiding this comment.
I think if we don't have a name, then we don't have a [project] table, so we don't have a version?
| let pyproject_path = project.root().join("pyproject.toml"); | ||
| let Some(name) = project.project_name().cloned() else { | ||
| return Err(anyhow!( | ||
| "There is no 'project.name' field in: {}", |
There was a problem hiding this comment.
I think I'd stylize this as: "Missing project.name field in: {}" (note the backticks)
This MR contains the following updates: | Package | Update | Change | |---|---|---| | [astral-sh/uv](https://github.com/astral-sh/uv) | patch | `0.7.6` -> `0.7.7` | MR created with the help of [el-capitano/tools/renovate-bot](https://gitlab.com/el-capitano/tools/renovate-bot). **Proposed changes to behavior should be submitted there as MRs.** --- ### Release Notes <details> <summary>astral-sh/uv (astral-sh/uv)</summary> ### [`v0.7.7`](https://github.com/astral-sh/uv/blob/HEAD/CHANGELOG.md#077) [Compare Source](astral-sh/uv@0.7.6...0.7.7) ##### Python - Work around third-party packages that (incorrectly) assume the interpreter is dynamically linking libpython - Allow the experimental JIT to be enabled at runtime on Python 3.13 and 3.14 on macOS on aarch64 aka Apple Silicon See the [`python-build-standalone` release notes](https://github.com/astral-sh/python-build-standalone/releases/tag/20250521) for more details. ##### Bug fixes - Make `uv version` lock and sync ([#​13317](astral-sh/uv#13317)) - Fix references to `ldd` in diagnostics to correctly refer to `ld.so` ([#​13552](astral-sh/uv#13552)) ##### Documentation - Clarify adding SSH Git dependencies ([#​13534](astral-sh/uv#13534)) </details> --- ### Configuration 📅 **Schedule**: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined). 🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied. ♻ **Rebasing**: Whenever MR becomes conflicted, or you tick the rebase/retry checkbox. 🔕 **Ignore**: Close this MR and you won't be reminded about this update again. --- - [ ] <!-- rebase-check -->If you want to rebase/retry this MR, check this box --- This MR has been generated by [Renovate Bot](https://github.com/renovatebot/renovate). <!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiI0MC4yMy4xIiwidXBkYXRlZEluVmVyIjoiNDAuMjMuMSIsInRhcmdldEJyYW5jaCI6Im1haW4iLCJsYWJlbHMiOlsiUmVub3ZhdGUgQm90Il19-->
This adopts the logic from
uv removefor locking and syncing, as the scope of the changes made are ultimately similar. Unlikeuv removethere is no support for modifying PEP723 scripts, as these are not versioned.In doing this the
versioncommand gains a truckload of args for configuring lock/sync behaviour. Presumably most of these are passed via settings or env files, and not of particular concern.The most interesting additions are:
--frozen: makesuv versionwork ~exactly as it did before this PR--locked: errors if the lockfile is out of date--no-sync: updates the lockfile, but doesn't run the equivalent ofuv sync--package name: a convenience for referring to a package in the workspaceNote that the existing
--dry-runflag effectively implies--frozen.Fixes #13254
Fixes #13548