vLLM's build now imports setuptools_rust unguarded, and that makes Rust non-optional

According to a dev.to walk-through run on an AWS EC2 G5g instance, vLLM's `setup.py` imports `from setuptools_rust.build import build_rust` at module scope on line 21, with no `try`, no feature flag and no opt-out ^[1]. The author reports that metadata generation does not happen without it, so at v0.27.2rc0 you cannot build vLLM from source without Rust in the picture ^[2][3].

This is not a stray line. The same walk-through says that since PR #40848, merged 2026-05-21, vLLM vendors a 14-crate Rust workspace: bench, chat, cmd, engine-core-client, llm, managed-engine, metrics, mock-engine, parser, parser/python, server, text, tokenizer and tracing ^[4], on edition 2024 with resolver 3 ^[5]. Two artifacts come out of it: `vllm-rs`, an axum frontend described as a drop-in replacement for the Python FastAPI server, and `vllm._rust_tool_parser`, a PyO3 extension module ^[6][7]. The author's characterisation is that the surface has been growing since it landed ^[8].

Most people have not felt this because `pyproject.toml` declares `setuptools-rust>=1.9.0` in `[build-system] requires`, and under normal build isolation pip installs it for you into a clean environment ^[9][10]. The toolchain was always required; isolation was hiding it ^[11].

Isolation stops being an option the moment the declared `torch == 2.13.0` pin is wrong for your hardware ^[9]. The walk-through's case: PyPI aarch64 torch wheels are built for sm_80 and up with no sm_75, which defeats the reason for building from source on a T4G in the first place ^[12]. The prescribed path is `python use_existing_torch.py` followed by `pip install -e . --no-build-isolation` ^[13]. That flag switches off automatic installation of every entry in the requires list, so `setuptools_rust` becomes yours to supply, and it surfaces as a bare `ModuleNotFoundError` during metadata generation, minutes into a build with nothing visibly Rust about it ^[14][15]. The author also flags the interpreter trap: install it into the Python that owns the torch you are building against, which on the DLAMI is `/opt/pytorch/bin/python3` and not the system `python3` ^[16].

The undocumented one is protobuf. `vllm-rs` depends on the `vllm-server` crate, `vllm-server` builds gRPC stubs with tonic and prost, and `prost-build` shells out to `protoc` ^[17]. Without `protobuf-compiler` installed the frontend binary is simply not built, and the author says that failure is not loud ^[18], while the tool parser has no protobuf dependency and builds either way ^[19]. The consequence is an asymmetric partial success: a build that reports no error and quietly ships the PyO3 parser without the axum server ^[20]. Toolchain installation itself is unremarkable on ARM: standard rustup, `stable-aarch64-unknown-linux-gnu`, rustc 1.97.1 ^[21]. The AWS Deep Learning ARM64 AMI ships a runtime rather than a build environment, and by the author's count four of six prerequisites are on the operator ^[22].

Worth watching: whether that import ever gets a guard or a feature flag, whether `protoc` appears in vLLM's documented build prerequisites rather than in third-party write-ups, and whether the crate count keeps climbing past 14. All of the above is one author's account of one machine, published twice on dev.to ^[23]; the line number is checkable in the tree.