`compute build` can validate the wrong `cargo`

[lonnen]

Version

Fastly CLI version v16.0.0 (Homebrew)
Built with go version go1.26.5 darwin/arm64 (2026-08-27)
Viceroy version: viceroy 0.20.1

macOS 26.6.2, Homebrew 6.0.19

What happened

I used homebrew to install both rust and rustup on my machine. I have wasm32-wasip1 installed, but homebrew's rust and cargo shadows the rustup version. When I init a new compute service the preflight check detects wasm32-wasip1 and passes, and the build fails ~20 crates in with unhelpful advice that won't fix the issue.

In a clean directory I ran:

$ fastly compute init --non-interactive --language rust \
  --from https://github.com/fastly/compute-starter-kit-rust-default
$ fastly compute build

Result:

✓ Verifying fastly.toml
✓ Identifying package name
✓ Identifying toolchain
✗ Running [scripts.build]

INFO: Command output:
--------------------------------------------------------------------------------
   Compiling proc-macro2 v1.0.106


   ... ~20 more crates ...


error[E0463]: can't find crate for `core`
  = note: the `wasm32-wasip1` target may not be installed
  = help: consider downloading the target with `rustup target add wasm32-wasip1`

error[E0463]: can't find crate for `std`
  = note: the `wasm32-wasip1` target may not be installed
  = help: consider downloading the target with `rustup target add wasm32-wasip1`

error: could not compile `itoa` (lib) due to 1 previous error
warning: build failed, waiting for other jobs to finish...
error: could not compile `stable_deref_trait` (lib) due to 1 previous error


   ... 5 more `could not compile` lines ...
--------------------------------------------------------------------------------

ERROR: error during execution process (see 'command output' above): exit status 101.

Expected

I suppose I expected that it would init without an error, but after figuring out the PATH shadowing I'd be happy with a preflight check and an actionable error.

Investigation

The target is installed in rustup:

$ rustup target list --installed
aarch64-apple-darwin
wasm32-wasip1

$ rustup target add wasm32-wasip1
info: component rust-std for target wasm32-wasip1 is up to date

So I look at the rest of the environment to see which version of rust / cargo / the toolchain I'm running.

$ command -v cargo rustc
/opt/homebrew/bin/cargo
/opt/homebrew/bin/rustc

$ cargo --version
cargo 1.97.1 (c980f4866 2026-06-30) (Homebrew)

$ rustup which cargo
/Users/lonnen/.rustup/toolchains/stable-aarch64-apple-darwin/bin/cargo

$ echo "$PATH" | tr ":" '\n'
...
/Users/lonnen/.cargo/bin
/opt/homebrew/bin
/opt/homebrew/sbin
...

[kpfleming]

I'm very curious how this happened... both invocations by the CLI run cargo, so they should run the same one. What is in scripts.build in your fastly.toml?

[lonnen]

I'm hitting this on a bare starterkit:

~/workspace
$ mkdir cli-issues-1897

~/workspace
$ cd cli-issues-1897

~/workspace/cli-issues-1897
$ fastly compute init --non-interactive --language rust \
  --from https://github.com/fastly/compute-starter-kit-rust-default

Creating a new Compute project (using --from to locate package template).

Press ^C at any time to quit.

✓ Validating directory permissions

✓ Fetching package template

✓ Reading fastly.toml
✓ Setting package name in manifest to "cli-issues-1897"
✓ Setting description in manifest
✓ Setting authors in manifest to '********@gmail.com'
✓ Setting language in manifest to 'rust'
✓ Saving manifest changes
✓ Initializing package

Initialized package cli-issues-1897 to:
        /Users/lonnen/workspace/cli-issues-1897

To publish the package (build and deploy), run:
        fastly compute publish

To learn about deploying Compute projects using third-party orchestration tools, visit:
        https://www.fastly.com/documentation/guides/integrations/orchestration

SUCCESS: Initialized package cli-issues-1897

~/workspace/cli-issues-1897
$ fastly compute build
✓ Verifying fastly.toml
✓ Identifying package name
✓ Identifying toolchain
✗ Running [scripts.build]

INFO: Command output:
--------------------------------------------------------------------------------
   Compiling proc-macro2 v1.0.106
   Compiling quote v1.0.46
   Compiling unicode-ident v1.0.24
   Compiling stable_deref_trait v1.2.1
   Compiling serde_core v1.0.229
   Compiling litemap v0.8.2
   Compiling writeable v0.6.3
   Compiling icu_normalizer_data v2.2.0
   Compiling icu_properties_data v2.2.0
   Compiling version_check v0.9.5
   Compiling utf8_iter v1.0.4
   Compiling itoa v1.0.18
   Compiling smallvec v1.15.2
   Compiling typenum v1.20.1
error[E0463]: can't find crate for `core`
  |
  = note: the `wasm32-wasip1` target may not be installed
  = help: consider downloading the target with `rustup target add wasm32-wasip1`

error[E0463]: can't find crate for `std`
  |
  = note: the `wasm32-wasip1` target may not be installed
  = help: consider downloading the target with `rustup target add wasm32-wasip1`

For more information about this error, try `rustc --explain E0463`.
error: could not compile `itoa` (lib) due to 1 previous error
warning: build failed, waiting for other jobs to finish...
error: could not compile `stable_deref_trait` (lib) due to 1 previous error
error: could not compile `smallvec` (lib) due to 1 previous error
error: could not compile `litemap` (lib) due to 1 previous error
error: could not compile `writeable` (lib) due to 1 previous error
error: could not compile `utf8_iter` (lib) due to 1 previous error
error: could not compile `typenum` (lib) due to 1 previous error
--------------------------------------------------------------------------------

ERROR: error during execution process (see 'command output' above): exit status 101.

Here are some steps you can follow to debug the issue:

- Re-run the fastly command with the --verbose flag to see more information.
- Is the required language toolchain (node/npm, rust/cargo etc) installed correctly?
- Is the required version (if any) of the language toolchain installed/activated?
- Were the required dependencies (package.json, Cargo.toml etc) installed?
- Did the build script (see fastly.toml [scripts.build]) produce a ./bin/main.wasm binary file?
- Was there a configured [scripts.post_build] step that needs to be double-checked?

For more information on fastly.toml configuration settings, refer to https://www.fastly.com/documentation/reference/compute/fastly-toml

fastly.toml look like this:

~/workspace/cli-issues-1897
$ cat fastly.toml
# This file describes a Fastly Compute package. To learn more visit:
# https://www.fastly.com/documentation/reference/compute/fastly-toml

authors = ["********@gmail.com"]
cloned_from = "https://github.com/fastly/compute-starter-kit-rust-default"
description = ""
language = "rust"
manifest_version = 3
name = "cli-issues-1897"
service_id = ""

[local_server]

[scripts]
  build = "cargo build --profile release"

rust-toolchain.toml specifies wasm32-wasip1

~/workspace/cli-issues-1897
$ cat rust-toolchain.toml
[toolchain]
channel = "stable"
targets = [ "wasm32-wasip1" ]
profile = "default"

Theory

The CLI checks the toolchain file for the presence of the correct target and marks a success. rust-toolchain.toml is specific to rustup, so when cargo is eventually invoked and it gets the homebrew cargo (not shimmed by rustup) the rust-toolchain.toml file is ignored.

This could be detected by comparing the following:

#!/usr/bin/env bash
set -uo pipefail

# Detect whether the cargo on $PATH is a rustup proxy.
#
# A bare cargo ignores an invalid toolchain, reports its own version 
# and succeeds. A rustup proxy fails when it cannot be found.
#
# Exit codes:
#   0  cargo is a rustup proxy
#   1  cargo is not a rustup proxy
#   2  no cargo on $PATH

cargo=$(command -v cargo) || { echo 'no cargo on $PATH'; exit 2; }

if RUSTUP_TOOLCHAIN=nonexistent-toolchain.invalid "$cargo" --version >/dev/null 2>&1; then
  printf '%s is NOT a rustup proxy\n' "$cargo"
  exit 1
fi

printf '%s is a rustup proxy\n' "$cargo"

edit: fixup script docstring

[lonnen]

One more detail that explains how I ended up here: rather than curling the install script from rust-lang.org, I use homebrew to install both rust and rustup. I just connected this missing detail from the rustup book:

Please note that Rust tools like rustc and cargo are not available via $PATH by default in this rustup distribution (see homebrew-core#177582 for more details). You might want to add $(brew --prefix rustup)/bin to $PATH to make them easier to access.

So this issue is an artifact of my personal setup, for sure, but maybe it's worth detecting and warning about in the pre-flight check all the same.

[kpfleming]

The CLI checks the toolchain file for the presence of the correct target

That code path is only taken when defaultBuild is true, and that is only true when fastly.toml does not contain a scripts.build value, but yours does. I don't think the CLI is looking at rust-toolchain.toml in your situation at all.

[kpfleming]

The normal 'version check' for Rust is here:

cli/pkg/commands/compute/language_rust.go

Line 322 in f0812fd

versionCommand := "cargo version --quiet"

If that doesn't run the same copy of cargo as cargo build does, then I don't think there's anything the CLI could do to resolve the situation.

[lonnen]

That's definitely the same copy of cargo being invoked in both. If I step back I'd describe my issue as this:

1. I run fastly compute build
2. the rust compiler has an error and claims running a rustup command will fix the issue
3. the suggestion says the missing toolchain is already installed, because rustup exists on my machine but late in the path
4. the problem reoccurs because the homebrew cargo is not actually managed by rustup

I think it would be valid to say this isn't a problem for us to mitigate in our cli. It could also be ergonomic to determine if cargo is not a rustup proxy and provide a warning. We could also explicitly invoke rustup's cargo instead of whatever cargo is first on the path with something likeRUSTC="$(rustup which --toolchain stable rustc)" "$(rustup which --toolchain stable cargo)", but that seems fragile

[kpfleming]

Agreed, and we don't have any dependency (in the normal case) on rustup so we can't mandate its use.