Skip to content

Commit a644df8

Browse files
committed
Clarify what the fresh-resolution test guards
With uv.lock committed, bare uv run consumes the lock and never resolves fresh. The fresh resolve happens on lock regeneration (uv lock after any pyproject.toml change) and on uv run's silent re-lock of a stale lockfile; say that instead of the bare-machine claim.
1 parent d98df3d commit a644df8

1 file changed

Lines changed: 13 additions & 10 deletions

File tree

source/isaaclab/test/install_ci/misc/test_uv_fresh_resolution_smoke.py

Lines changed: 13 additions & 10 deletions
Original file line numberDiff line numberDiff line change
@@ -8,8 +8,8 @@
88
- (none: the test resolves dependencies only and does not install anything)
99
Tests:
1010
- uv lock --upgrade --dry-run -> verify the full dependency graph (all extras, all
11-
platforms) re-resolves from the live public indexes, i.e. ``uv run`` works from
12-
a bare machine
11+
platforms) re-resolves from the live public indexes, so the lockfile can be
12+
regenerated after any pyproject.toml change
1313
"""
1414

1515
from __future__ import annotations
@@ -26,11 +26,13 @@ class Test_Uv_Fresh_Resolution_Smoke:
2626
"""A fresh, full-graph resolution must succeed from the public indexes.
2727
2828
``uv lock --upgrade --dry-run`` re-resolves every dependency, extra, and platform
29-
fork from scratch without writing the lockfile or installing anything - exactly
30-
what ``uv run`` does on a bare machine before the first lock exists. This is the
31-
check that catches a pin that only resolves against internal infrastructure
32-
(e.g. an unpublished ``ovphysx==0.5.2+head...`` build) or a marker split uv
33-
cannot satisfy.
29+
fork from scratch, ignoring the committed lockfile and without writing or
30+
installing anything. The committed lock shields ``uv run`` users from resolution,
31+
but a fresh resolve still happens whenever the lock must be regenerated: any
32+
contributor changing ``pyproject.toml`` runs ``uv lock``, and ``uv run`` silently
33+
re-resolves when the lock is stale. This is the check that catches a pin that
34+
only resolves against internal infrastructure (e.g. an unpublished
35+
``ovphysx==0.5.2+head...`` build) or a marker split uv cannot satisfy.
3436
3537
Complements the neighbouring checks: ``test_uv_lock_check_smoke`` validates the
3638
committed lock is current, the ``uv_run/`` tests validate the committed lock
@@ -48,7 +50,8 @@ def test_uv_lock_upgrade_resolves_all_extras_from_public_indexes(self, isaaclab_
4850
"""Verify ``uv lock --upgrade --dry-run`` resolves the full graph fresh."""
4951
result = run_cmd(["uv", "lock", "--upgrade", "--dry-run"], cwd=isaaclab_root, timeout=880)
5052
assert result.returncode == 0, (
51-
"Fresh full-graph resolution failed, so `uv run` is broken on a bare machine."
52-
" A dependency (often in an optional extra) no longer resolves from the public"
53-
f" indexes, or a marker split is unsatisfiable:\n{result.stdout}\n{result.stderr}"
53+
"Fresh full-graph resolution failed: the lockfile can no longer be regenerated"
54+
" (`uv lock` after a pyproject.toml change will fail, and `uv run` will fail on"
55+
" a stale lock). A dependency, often in an optional extra, no longer resolves"
56+
f" from the public indexes, or a marker split is unsatisfiable:\n{result.stdout}\n{result.stderr}"
5457
)

0 commit comments

Comments
 (0)