Cargo add vs dependencies

In the "Installation" section of https://github.com/async-rs/async-std there's a note that installation is done through running $ cargo add async-std. What does this actually do? I'm used to simply adding the crate as a dependency to the Cargo.toml file, but should I be cargo add:ing crates?

Here's the tool's output when run with the help command:

> cargo add -h
Usage:
    cargo add [options] <dep>...
    cargo add [options] <dep> (--version | --path | --git) <source>
    cargo add -h | --help

Options:
    --manifest-path PATH    Path to the manifest to add a dependency to.
    -h --help               Show this help page.

Add a dependency to the crate's Cargo.toml file. If no source is specified, the
source will be set to a wild-card version dependency from the source's default
crate registry.

If a version is specified, it will be validated as a valid semantic version
requirement. No other kind of source will be validated, and the registry will
not be polled to guarantee that a crate meeting that version requirement

And here's its github page:

It does, in fact do the same thing as just adding it to Cargo.toml.

1 Like

Recently cargo add has made itself useful in my workflow, while before that I used to add dependencies manually.
I have to say it's an improvement on 2 fronts:

  1. Not having to manually do the work aka the standard benefits of automation, and
  2. I don't have to look up the version numbers anymore. See my workflow used to be open Cargo.toml, look up the version number on crates.io, and add the information manually.

Now I just need to know the name of the crate.

2 Likes

I think it's cargo-edit (which includes a cargo add tool) that async-std is recommending - cargo-add has a deprecation notice in the readme directing people to use that instead.

4 Likes