make `uv version` lock and sync #13317

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Merged

Gankra merged 8 commits into main from gankra/sync-version

May 21, 2025

Contributor

Gankra commented May 6, 2025 •

edited

Loading

This adopts the logic from uv remove for locking and syncing, as the scope of the changes made are ultimately similar. Unlike uv remove there is no support for modifying PEP723 scripts, as these are not versioned.

In doing this the version command 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: makes uv version work ~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 of uv sync
--package name: a convenience for referring to a package in the workspace

Note that the existing --dry-run flag effectively implies --frozen.

Fixes #13254
Fixes #13548

Contributor Author

Gankra commented May 6, 2025

Note for reviewers: print_version, bumped_version, and similar "compute the version change" logic should be completely unchanged. All the project read/write logic was completely rewritten and can be reviewed in a vacuum.

The added code is nearly an exact copy paste from uv::commands::project::remove::remove, but with the support for RemoveTarget::Script removed.

Gankra added the bug label

Contributor Author

Gankra commented May 6, 2025

I should almost certainly add some new tests for this...

Contributor Author

Gankra commented May 6, 2025 •

edited

Loading

Some new sample outputs

$ uv version
myfast 1.2.8

$ uv version 1.2.9
Resolved 36 packages in 7ms
Audited 34 packages in 0.02ms
myfast 1.2.8 => 1.2.9

$ uv version 1.2.10 --no-sync
Resolved 36 packages in 7ms
myfast 1.2.9 => 1.2.10

$ uv version 1.2.11 --frozen 
myfast 1.2.10 => 1.2.11

uvloc version 1.2.12 --locked 
Resolved 36 packages in 7ms
error: The lockfile at `uv.lock` needs to be updated, but `--locked` was provided. To update the lockfile, run `uv lock`.

...it occurs to me that --locked is basically an unusable cli flag for add/remove/version but well, that's a pre-existing truth I guess. I suppose it works for:

uv version --locked (no values to set)
uv version --locked the-version-thats-already-there (noop)

Member

konstin commented May 6, 2025

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 approved these changes

View reviewed changes

Member

charliermarsh left a comment

This looks great! The one thing that's missing is a few tests to verify that the lockfile is actually getting updated.

HenriBlacksmith commented May 20, 2025

Any plans to merge this fix?

Gankra mentioned this pull request

Support workspaces in uv version #13548

Closed

Gankra added 4 commits

May 20, 2025 13:44


          make the uv version lock and sync

fef956c


          update help snaps

5cad5dc


          add some tests and make the sync Sufficient

03ffc85


          implement frozen read semantics

af44ca6

Gankra force-pushed the gankra/sync-version branch from bd5a0a1 to af44ca6 Compare

May 20, 2025 17:44


          refmt

7e59e85

Gankra commented

View reviewed changes

crates/uv/src/commands/project/version.rs Outdated

Comment on lines 330 to 337

+                  // 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()
+                  };

Contributor Author

Gankra May 20, 2025

This logic for mapping the package to the version is extremely dubious to me...

Gankra commented

View reviewed changes

crates/uv/src/commands/project/version.rs Outdated

Comment on lines 104 to 109

+                  let pyproject_path = project.root().join("pyproject.toml");
+                  let name = project
+                      .pyproject_toml()
+                      .project
+                      .as_ref()
+                      .map(|project| project.name.clone());

Contributor Author

Gankra May 20, 2025

this is how we get the "name" we'll be looking up in the lockfile

Contributor Author

Gankra May 20, 2025

I think this part can at least be simplified to project.project_name()

Gankra commented

View reviewed changes

crates/uv/src/commands/project/version.rs

Comment on lines +219 to +239

+                  // 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?
+                  };

Contributor Author

Gankra May 20, 2025 •

edited

Loading

This is how we find the project we use to lookup the pyproject.toml to get the name from


          cleanup method and add some more checks

12d106f

zanieb reviewed

View reviewed changes

crates/uv/src/commands/project/version.rs Outdated

+              /// Find the pyproject.toml we're modifying
+              ///
+              /// Note that `uv version` never needs to support PEP723 scripts, as those are unversioned.

Member

zanieb May 20, 2025

Nit: This is the proper style

Suggested change

      
            /// 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.

charliermarsh reviewed

View reviewed changes

crates/uv/src/commands/project/version.rs Outdated

+                  )?;
+                  let pyproject_path = project.root().join("pyproject.toml");
+                  let name = project.project_name().cloned();

Member

charliermarsh May 20, 2025

I think if we don't have a name, then we don't have a [project] table, so we don't have a version?


          cleanup name handling

ebbbd92

charliermarsh reviewed

View reviewed changes

crates/uv/src/commands/project/version.rs Outdated

+                  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: {}",

Member

charliermarsh May 21, 2025

I think I'd stylize this as: "Missing project.name field in: {}" (note the backticks)


          cleanup message

2b06125

Gankra merged commit 38884da into main

86 checks passed

Gankra deleted the gankra/sync-version branch

May 21, 2025 13:46

BrewTestBot mentioned this pull request

uv 0.7.7 Homebrew/homebrew-core#224443

Merged

ggydush mentioned this pull request

Is it necessary to have project's version baked into the lockfile #13604

Open

tmeijn pushed a commit to tmeijn/dotfiles that referenced this pull request


          build(deps): update astral-sh/uv to v0.7.7

1c510d9

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 ([#&#8203;13317](astral-sh/uv#13317))
-   Fix references to `ldd` in diagnostics to correctly refer to `ld.so` ([#&#8203;13552](astral-sh/uv#13552))

##### Documentation

-   Clarify adding SSH Git dependencies ([#&#8203;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-->

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug