Repository navigation
ci: uv installs on the slow tier, no-aimnet and the documentation jobs - #242
Merged
Merged
Conversation
The fast legs moved to uv last change and their installs went from 78 s and 57 s to 8 s and 7 s. The jobs still on pip were the ones where that mattered more: 63-78 s per slow shard, 86 s for no-aimnet, 50 s for the documentation build -- each of them longer than an entire fast leg now takes, and the slow tier is what the run's gate waits on. Converting them is worth more than everything in the two changes before it. Both uv flags carry over because both are load-bearing rather than tuning. --index-strategy unsafe-best-match, because uv's default stops at the first index carrying a package at all and the PyTorch index has a requests (2.28.1) far below this project's floor, so the default resolves nothing; --system, because a runner has no virtual environment and uv declines to touch an interpreter it was not pointed at. The resolution is unchanged, checked per job rather than assumed. Each converted environment was built twice in one runner, once with the pip command it used to run and once with the uv command it runs now, and frozen with the same tool on both sides: the two dependency sets are identical, torch is the +cpu build, and there is no nvidia_* or triton wheel either way. For no-aimnet that check is the point of the job rather than a formality -- its value is which package it ends up without, so both freezes were also asserted to lack aimnet and both interpreters to fail `import aimnet`. cache: pip goes with them. uv does not read pip's HTTP cache, so restoring the 627 MB entry would cost about 5 s of a job's setup to feed a tool that never looks at it. No job writes those entries now either, so the stored ones age out of GitHub's 7-day window unused; that costs nothing, because the only cache a run still depends on is the model-weight entry the slow shards restore, which cache-keepalive.yml holds open. The lint job keeps pip: it installs ruff and nothing else, in 2 s, which is less than `pip install uv` would add. publish.yml is left alone -- its pip install of a built wheel into a throwaway virtual environment is a check that the published artifact installs the way a user installs it. Two comments that had gone stale are corrected while the files are open: the fast legs' note on cache: pip said the other jobs still wrote that cache, and docs.yml described tests.yml's cron as weekly for the model cache, which went monthly when cache-keepalive.yml took that job over.
Builds each converted job's environment twice in the same runner -- the pip command it used to run and the uv command it runs now -- and fails if the freezes differ. Three legs, one per extras set: ase,ani,dev for the slow shards, ani,ase,dev plus the uninstall for no-aimnet, ase,ani,docs for the documentation jobs. Both sides are frozen with the same tool, because `uv pip freeze` and `pip freeze` disagree about pip and setuptools themselves and that difference says nothing about the resolution. The project's own editable self-entry is recorded differently by the two installers, so it is reported separately rather than ignored. Deleted before the pull request's head; it exists to produce one measurement.
It had one measurement to produce and produced it, in run 41546099135: three legs, one per converted extras set, each building the environment twice in the same runner. ase,ani,dev froze to 118 distributions on both sides, ani,ase,dev minus aimnet to 117, and ase,ani,docs to 106; every pair was byte-identical, torch was 2.13.0+cpu throughout with no nvidia_* and no triton, and in the no-aimnet leg both freezes lacked aimnet and both interpreters failed to import it. The logs and the uploaded freezes are what remains of it. That run also measured the two installers against each other with nothing else differing: 81-90 s for pip, 9-10 s for uv. The install comment now carries those numbers instead of a ratio.
`pip install uv` took whatever was current at run time, at five sites across two workflows, in front of every gate in the repository. A uv release that changed resolution -- `--index-strategy` behavior is exactly the kind of thing that moves -- would have broken all of them at once on whichever pull request happened to be open, with no diff to point at. That is the same fails-on-luck mode the lint job's comment gives as the reason ruff is pinned exactly, and every action here is SHA-pinned for it too. It was also inconsistent with the argument already written next to it: that comment declines a marketplace action partly to avoid one more pinned dependency, which is a reason against the action, not a reason to leave the installer floating. One workflow-level UV_VERSION per file, referenced at each install site rather than a literal repeated five times. It cannot go in pyproject.toml's dev extra, which was the obvious place: uv is what installs the project, so it has to exist before any extra does. 0.13.6, because that is the version that produced every number now recorded in these comments -- the 9-10 s installs, the 165 s run, and the three freeze comparisons that showed pip and uv resolving identically. Picking latest instead would have left the measurements describing a version no longer in use. Raising it means raising both files together and re-checking the resolution rather than assuming it held.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The fast legs moved to uv last change; these are the jobs that were left, and
the ones where the install actually cost something. Six install steps convert:
the four slow shards,
no-aimnet, and bothdocs.ymljobs.Result
Per install step:
Built head to head in one runner, with nothing else differing: 81-90 s with
pip, 9-10 s with uv.
No job's install is its largest step any more. The gate's binding constraint is
now shard 1's own test step (120 s of a 152 s job), so the next lever is the
shard balance -- 120 / 109 / 105 / 74 test-seconds -- which this change
deliberately leaves alone.
The two flags
--index-strategy unsafe-best-match: uv's default stops at the first indexthat has a package at all, and the PyTorch index carries a
requests(2.28.1)far below this project's floor, so the default resolves nothing and the install
fails outright.
--system: a runner has no virtual environment and uv declinesto touch an interpreter it was not pointed at.
The resolution is unchanged, checked per job
A temporary workflow (run 41546099135, removed from this branch's head) built
each converted environment twice in one runner -- the pip command the job used
to run and the uv command it runs now -- and froze both with the same pip
binary:
ase,ani,dev2.13.0+cpuani,ase,devminus aimnetno-aimnet2.13.0+cpuase,ani,docsbuild,linkcheck2.13.0+cpuFor
no-aimnetthe absence is the point, so it was asserted rather thaninferred: on both environments
aimnetis missing from the freeze andpython -c "import aimnet"fails. The 118 to 117 drop is aimnet and nothing else onboth sides, so
uv pip uninstallleft its transitive dependencies in placeexactly as
pip uninstall -ydid.cache: pipgoes with themuv does not read pip's HTTP cache, so the restore was 6-10 s of setup feeding a
tool that never looks at it. Nothing writes those entries now either; the five
stored ones (~3.3 GB of the repository's 10 GB budget) age out on their own.
The only cache a run still depends on is the 31 MB model-weight entry the slow
shards restore, which
cache-keepalive.ymlholds open -- that file needs nochange and gets none.
uv is pinned
UV_VERSION: "0.13.6"as one workflow-level value per file, referenced aspip install "uv==${UV_VERSION}"at each of the five sites. Unpinned, uv was aresolver taking whatever version was current at run time in front of every gate
here -- the same fails-on-luck mode that pins
ruffexactly and SHA-pins everyaction. The comment that declined a marketplace action partly to avoid another
pinned dependency now says why that is an argument against the action, not for
leaving the installer floating.
0.13.6 because that is the version every number above was measured with,
confirmed from the logs of all four runs cited. It cannot go in the
devextra: uv is what installs the project, so it exists before any extra does.
The pin costs nothing. On the pinned head (run 41548392879) the gate is 181 s
and every install is 6-9 s, unchanged; the 165 to 181 s difference is entirely
shard 1's test step (120 s then 137 s), which is the tier's ordinary noise. Two
runs put the gate at 165-181 s against a 243-304 s baseline.
Not converted
lintinstalls ruff and nothing else in 2 s, which is less thanpip install uvwould add.publish.ymlis out of scope, and separately its pip install ofthe built wheel is deliberately the way a user would install it.
Two comments that had gone stale are corrected while the files are open: the
fast legs' note on
cache: pipclaimed the other jobs still wrote that cache,and
docs.ymldescribedtests.yml's cron as weekly for the model cache,which went monthly when
cache-keepalive.ymltook that job over.Check Linksis skipped on a pull request, so its install was exercised bydispatching the workflow on this branch (run 41547117953, green). Its pip
baseline is the 2026-11-02 monthly cron, run 41402781229.