feat(bbup): add --no-modify-path, dedupe PATH entries - #25060
Merged
Merged
Conversation
fcarreiro
added a commit
that referenced
this pull request
Jul 30, 2026
The --no-modify-path flag install_bb relies on is proposed on its own against next; keeping a copy here would just conflict with it.
fcarreiro
enabled auto-merge
July 30, 2026 11:26
fcarreiro
added a commit
that referenced
this pull request
Jul 30, 2026
The --no-modify-path flag install_bb relies on is proposed on its own against next; keeping a copy here would just conflict with it.
nventuro
approved these changes
Jul 30, 2026
nventuro
left a comment
nventuro
left a comment
Contributor
There was a problem hiding this comment.
Looks great! Should we use this flag in bbup/run_test.sh?
fcarreiro
added this pull request to the merge queue
Jul 30, 2026
nventuro
removed this pull request from the merge queue due to a manual request
Jul 30, 2026
Scripted installs need bb placed in a chosen directory (BB_PATH) without editing the invoking user's shell config; --no-modify-path skips update_shell_config for them. The config edits it does make are idempotent now: every run used to append another PATH line to .bashrc/.zshrc/config.fish.
fcarreiro
force-pushed
the
fc/bbup-no-modify-path
branch
from
July 30, 2026 14:31
54d04e3 to
b7c82af
Compare
fcarreiro
enabled auto-merge
July 30, 2026 14:31
Contributor
Author
Made Claude modify/add test cases. |
fcarreiro
added this pull request to the merge queue
Jul 30, 2026
fcarreiro
added a commit
that referenced
this pull request
Jul 30, 2026
Implements the labs-repo side of `labs-aztec-toolchain`: instead of linking locally built binaries, `build_labs` provisions the pinned toolchain from releases. Follows #25047 (merged). With the Makefile dependency on `noir bb-cpp-native` commented out, the monorepo takes the same downloaded toolchain, so `build_monorepo` is now unused — kept in case the foundation side wants it. Closes https://linear.app/aztec-labs/issue/A-1532/source-bbnargo-from-an-aztec-toolchain-directory-for-labs . ## Provisioning (`build_labs`) Pins at the top of the script: `BB_VERSION=6.0.0-nightly.20260729` and `NOIR_VERSION=1.0.0-beta.25`. Every source URL is env-overridable (`BBUP_URL`, `NOIRUP_URL`, `BB_AVM_URLS`, `NOIR_SOURCE_URL`) for testing and mirroring, and `NOIR_TAG` covers noir's two tag shapes (`v<semver>` for releases, unprefixed for nightlies). - **bb** via bbup, curled from `next` at build time and run with `BB_PATH=<toolchain bin>` + `--no-modify-path`. - **nargo + noir-profiler** via noirup, curled from noir-lang/noirup `main` and run with an isolated `NARGO_HOME` (noir releases ship the profiler next to nargo; no shell config or `~/.nargo` is touched). - **bb-avm** straight from the release: bbup's artifact name is hardcoded to the plain bb, so this fetches `barretenberg-avm-amd64-linux.tar.gz` itself, barretenberg mirror first and aztec-packages as fallback, matching bbup's order. It is published for amd64 linux only, so elsewhere it is skipped rather than fatal — its consumers (AVM proving) only run there anyway. - **acvm** compiled from the noir release source tarball, because nothing publishes it: no noir release asset, and `acvm_cli` is not on crates.io. Every path cargo writes to lives under the run's `mktemp -d` and dies with it — `CARGO_HOME` (so the fetched crates stay out of the user's registry cache), `CARGO_TARGET_DIR`, the `--root` install prefix, and the extracted source. Three details behind that: - Cargo runs from *inside* the source tree so rustup picks up noir's `rust-toolchain.toml`. From anywhere else the ambient cargo is used, and a cargo older than noir's MSRV fails the build (hit for real with a 1.85 on `PATH`). - `RUSTFLAGS` remaps the temp paths out of the binary. Left in, the `mktemp` name lands in the executable and every build of the same source produces different bytes, which would poison the pin hash and every downstream cache key derived from `bootstrap.sh hash`. - `GIT_COMMIT`/`GIT_DIRTY` are passed in because `noirc_driver`'s build script reads them from a git checkout, and a release tarball is not one. A build from scratch is ~5 minutes (~1.5 compiling, the rest fetching ~330 dependency crates that the isolated `CARGO_HOME` discards), so the built binary goes through the ci3 build cache under `labs-acvm-<noir version>-<platform>`. The key carries the platform explicitly since, unlike keys derived from `cache_content_hash`, it is otherwise just a version. ## Pin record and per-binary staleness `bin/.pin` records the pinned versions **and a `git hash-object` content hash per binary**, written only for those present — so an optional binary's absence is part of the record too. `is_current <binary> <release key> <version>` then answers for one binary: it exists, the recorded release matches the pin, and the recorded hash matches the actual contents. Matching versions alone would not catch a corrupted or swapped binary. Checks are per binary, feeding install flows that are coarser: bbup and noirup each provision a whole release in one shot, while bb-avm and acvm are provisioned individually. A corrupt `nargo` therefore re-runs only noirup; a missing `bb-avm` re-downloads only its artifact. Where a binary cannot be provisioned on the machine (bb-avm off amd64 linux, acvm with no cargo), `drop_unprovisionable` removes whatever sits in its place, so the record never attests contents from a different provisioning. Each install `rm -f`s its destination first: unpacking or copying onto a leftover symlink writes *through* it, into the linked build output. The record is written once before the acvm build and again at the end, so a failed source build does not cost the downloads that already succeeded; a stale acvm is dropped before that first write so an interrupted run cannot leave the record attesting contents that are about to be replaced. `noir_version` reads **only** the pin record: the binary reports its base cargo version, which cannot distinguish a nightly from the release it was cut from. `hash` covers the three required binaries plus bb-avm/acvm when present — what the toolchain provides, including their absence, is part of its identity. ## bbup `install_bb` runs bbup with `--no-modify-path`, which is not part of this PR: that flag and the idempotent `update_shell_config` go in through #25060 against `next`. Until it lands, `build_labs` with the default `BBUP_URL` fails on the unknown flag (tested here via a `file://` override); once it does, `BBUP_URL` can pin that commit instead of tracking `next`. ## Docs `labs-aztec-toolchain/README.md` describes what the component provisions and what consumers read from it; root `CLAUDE.md` now states the `$NARGO` default per side (`fnd/**` submodule build, `labs/**` toolchain); `noir-projects/labs/contract-snapshots/README.md` no longer points at the submodule build. ## Testing Real downloads and builds: - bb-avm fetched from the release (147 MB), `bb-avm --version` → `6.0.0-nightly.20260729`. - acvm built three times in fresh temp dirs → byte-identical every time (`git hash-object` `458823a1…`), `acvm version = 0.40.0`. Afterwards: temp dir gone, no `~/.cargo/bin/acvm`, and the user's registry cache entry count unchanged. - Cache round trip via `CACHE_LOCAL_DIR`: miss → build → upload (12 MB → 4.4 MB), then hit → restored with its exec bit in 0.26s instead of ~5 min, pin recording the restored hash. Staleness scenarios, with stand-in installers so no release traffic was involved: - cold install; no-op rerun; corrupt `nargo` → only noirup; missing `bb` → only bbup; missing `noir-profiler` → only noirup. - simulated non-amd64 (`setarch linux32`) → bb-avm skipped and dropped; no cargo on `PATH` → acvm skipped, dropped, and its hash absent from the record. - failed source download mid-build → record stays honest (no `acvm_hash`, corrupt file removed) and the next run retries only acvm, without re-downloading bb or nargo. - monorepo-style symlinks in `bin/` taken over by downloads with all five pretend build outputs left byte-identical. ## Notes - On a cache miss the acvm build is ~5 minutes, and ci3 only uploads from CI, so the first person to build a newly pinned noir version pays it locally. - The pin record attests contents from install time onward; it does not validate a fresh download against a known-good checksum. If we ever want that, the script would need to carry expected per-platform hashes.
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
2 participants
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.
What
--no-modify-pathskipsupdate_shell_config, so a scripted install can placebbin a chosenBB_PATHwithout editing the invoking user's.bashrc/.zshrc/config.fish.PATHline to each config.BB_PATH.Required for https://linear.app/aztec-labs/issue/A-1532/source-bbnargo-from-an-aztec-toolchain-directory-for-labs .
Why now
labs-aztec-toolchainprovisions its pinnedbbby fetchingbbupfrom this repo and running it with--no-modify-pathinto the component'sbin/. That branch pins the raw URL, so this has to be onnextbefore the pin can point at a commit.Verification
Ran the real script against the pinned nightly with
HOMEredirected to a scratch dir seeded with an empty.bashrc,.zshrcandconfig.fish:--no-modify-path:bbinstalled into the givenBB_PATH(bb --version→6.0.0-nightly.20260729), all three configs still 0 lines.