Two metadata files replace hand-built compiler commands
Cargo uses Cargo.toml and Cargo.lock to turn a Rust package into a repeatable set of compiler inputs. The manifest declares the package, dependencies, features, and build settings. The lockfile records the selected dependency versions. Cargo then fetches those dependencies and invokes rustc with the required arguments. This is why the same cargo build command works across projects that would otherwise need different compiler commands.
The Cargo Book describes 4 jobs: introduce package metadata, fetch and build dependencies, invoke the compiler or another build tool, and impose common project conventions. That scope reaches beyond downloading crates. The familiar commands for building, testing, documentation, and publishing all operate on the same package model. For a Rust application or library, replacing that model usually creates work without giving the team a better result.
One workspace shares one lockfile and output directory
A Cargo workspace gives its member packages 1 shared Cargo.lock and 1 shared output directory by default. Commands can target a selected package or every member. The root manifest can also centralize package metadata, dependencies, lint settings, and compiler profiles. That arrangement fits repositories containing several libraries, binaries, and support crates without making every member maintain its own copy of common settings.
There are boundaries worth learning before a workspace grows. Patch, replacement, and profile sections are read from the root manifest, not member manifests. A virtual workspace has no root package edition from which Cargo can infer a resolver, so it must name the resolver itself. Those rules are documented with concrete manifests, but they can surprise a team that treats a workspace as a loose folder of independent crates.
Source compilation needs an existing Rust toolchain
Building Cargo from source starts with an existing cargo and rustc, plus a C compiler and Git. That bootstrap requirement is easy to miss if you think of Cargo only as the tool being built. The README's release command is short, but the prerequisites may expand by platform and feature choice. Unix builds can need OpenSSL headers, and vendored OpenSSL can add Perl and Make.
The repository lists 4 native libraries that can be supplied by the system or built from vendored sources: libcurl, libgit2, libssh2, and zlib. Cargo recommends the vendored versions it tests. System copies can reduce local compilation, while vendoring reduces dependence on what a particular host has installed. Neither choice requires a hosted service, although publishing a crate later requires registry authentication.
What happened when we ran it
Our run at commit 7456cea installed 445 packages in 31 seconds and completed the build in 240 seconds. The fresh Debian checkout had 2,939 files, about 343,368 lines of source, and occupied 17.9 MB. We used an unprivileged container with 3 CPUs and 12 GB of RAM. The repository contained 4 CI workflow files and a tests directory, but no Dockerfile.
The test step failed after 143 seconds with exit code 101. Two attributes on tests requiring Rustup stable panicked during compilation. The message said the command /work/home/.cargo/bin/cargo was expected to be somewhere in PATH, but the file did not exist. Cargo's testsuite then stopped compiling after those 2 errors. The log does not establish why that executable was absent, so we do not assign a broader cause.
A successful 240-second build and a failed test compile answer different questions. The source and its dependencies could produce the build artifact in our sandbox. The contributor test environment was incomplete for the command the suite expected. Anyone changing Cargo should reproduce the documented toolchain layout before treating a release build as sufficient evidence that a patch is ready.
A build script executes package code before compilation
A package can place 1 build.rs file at its root, and Cargo will compile and run it before building the rest of that package. Typical uses include compiling bundled C, locating a system library, generating Rust modules, or applying platform-specific configuration. The script passes linker settings, environment values, and change triggers back to Cargo through specially formatted output.
That power changes the security model of a build. A newly selected dependency may execute its own build script, so a lockfile fixes the version but does not make the dependency passive. Restricted CI should keep secrets away from untrusted builds and review dependency changes. The documentation also warns that OUT_DIR persists across rebuilds and that cross-compilation checks must read Cargo's target environment variables rather than host-only cfg values.
Four publishing steps end with an authenticated registry upload
The cargo publish command performs 4 documented stages: checks package restrictions, creates a .crate archive, uploads it, and polls the registry index for the new package. The default destination is crates.io, though configuration can select another registry. Authentication comes from cargo login or registry token settings, so publishing has a credential boundary that ordinary local builds do not.
Cargo also releases differently from many GitHub projects. Its README says Cargo releases coincide with Rust releases and points readers to Rust release notes plus Cargo's detailed changelog. The GitHub latest-release endpoint returned no standalone release object. That absence is consistent with the stated release process and should not be read as a stale project signal.
The August 26 push and issue activity show live maintenance
GitHub recorded 15,429 stars, 1,660 open issues and pull requests combined, and a last push on August 26, 2026. The combined count is not a bug total. Open issues and pull requests were updated the same day, including discussion of install behavior, dependency resolution, compiler flags, incremental build time, and credential handling. The repository is plainly active even though its queue is large.
Cargo remains the sensible default inside a Rust-first codebase. Bazel or Buck2 becomes relevant when a company needs one graph across Rust and several other languages, especially when repository-wide orchestration outranks crates.io conventions. Even then, Cargo's manifests and ecosystem still matter to the Rust portion. For most teams, the decision is about what coordinates Cargo, not whether to discard it.