Cargo add makes dependency declarations part of the command interface

Adding a dependency involves more than inserting a package name. A project chooses its source, version requirement and features, and decides whether the package belongs to ordinary code, tests or a build script. Rust 1.62 brings those manifest-editing operations into Cargo through cargo add.

The 30 June announcement introduces the integrated command alongside a new default-variant annotation and lighter Linux synchronization implementations. Cargo add is useful because it exposes existing dependency choices through a consistent command interface. It does not make those choices disappear.

I still reach for Go first for many command-line programs, but Rust's tooling interests me where it makes a precise dependency model easier to use. A command that edits the manifest is valuable when its output remains an ordinary declaration that another engineer can inspect.

The operation adds or modifies a declaration

The command documentation shipped with this Cargo release says cargo add can create or modify dependencies. If a package is already present, the specified flags update its existing entry. This means repeated invocation is an editing operation with consequences for current configuration.

The release gives a familiar feature-selection example. From a package directory, this command requests serde with its derive feature.

cargo add serde --features derive

The command expresses a dependency and an enabled capability. It does not establish that serialization derives now exist on application types or that the application has implemented a particular data format. Those remain changes to source and behavior outside manifest editing.

That boundary is useful for reviewing automation. A script using cargo add can make dependency setup easier to reproduce, but the resulting manifest still needs to describe what the program intends to use. Successful command completion does not validate a package's suitability for the domain.

Source selection is an explicit choice

The versioned documentation supports registry requirements, local paths and Git repositories. The crate@version form selects a registry dependency with a stated constraint. Path and Git options select other source forms, and Git selection can specify a branch, tag or revision.

When no source is specified, the command makes a best effort based on available information. Its documented candidates include an existing dependency in another table, workspace membership and the latest registry release. That is helpful convenience, but it makes inspection of the selected declaration useful when several sources are plausible.

For example, a package already used as a development dependency can inform adding it elsewhere. The developer's intention is broader than simply asking a registry for a new package. Cargo has project context that a manual spelling exercise would otherwise require the user to inspect separately.

My preference is for convenience to produce visible configuration. A source chosen through project context can be reasonable, provided the manifest records it clearly. That preserves the ability to understand the build without rerunning the original interactive command.

Dependency sections carry different roles

The command has separate options for development and build dependencies. It also supports target-specific declarations. These choices determine where the declaration belongs in the manifest, rather than changing only the spelling of its version requirement.

That matters to maintenance because a test helper and a build-script library have different uses. Adding everything to the ordinary dependency table obscures those uses. The command interface gives the author a way to state the role while making the change.

Manifest selection is another explicit input. The documented manifest-path option chooses the file to edit, while the default searches the current directory and its parents. In a repository containing several packages, the working directory therefore contributes to the command's meaning unless the target manifest is specified.

This makes a useful distinction for scripts operating across packages. Choosing a manifest and choosing a target platform are separate operations. One identifies the package declaration being edited, while the other places the dependency in a platform-specific section within that declaration.

Features and aliases remain part of the package contract

Cargo add can enable named features and disable default features. It can mark a dependency optional or required, and it can assign a local dependency name through renaming. The available flags expose choices that matter to the resulting build graph.

Disabling default features does not mean selecting no functionality. The project can deliberately enable a narrower named set. Likewise, marking a dependency optional expresses a conditional relationship that other feature declarations can activate. An author still needs to understand the package's feature model.

The dependency specification documentation explains that renaming can separate the local crate name from the published package name. That remains true when a command writes the declaration. Reviewing the local alias alone does not identify the selected registry package or Git source.

These details are why the integrated command should be understood as manifest editing. It simplifies producing a declaration while leaving the declaration available for review. The important result is the source and configuration Cargo records, not the brevity of the command that produced it.

Linux locks lose an implementation allocation

The release also replaces Linux pthread-backed Mutex, Condvar and RwLock implementations with futex-based implementations. Its announcement explains that the pthread mutex representation could not move, which required an allocation behind the Rust value. The new implementation removes that extra allocation and substantially reduces internal state.

This is a different kind of simplification from cargo add. The synchronization API keeps its role while the implementation avoids machinery needed for pthread behavior that Rust's interface does not expose. The announcement explicitly treats the internal size as an implementation detail that may change.

I find that useful as a systems-language improvement because applications receive the benefit through the existing abstraction. It does not require rewriting synchronization around a new public lock type. The release illustrates two maintenance gains at different levels, an ordinary manifest operation becomes easier to express, while an established runtime operation needs less implementation storage.