As of Rust 1.41.0, you can use the following command to update crates to their latest version:

cargo install <crate>

This came from pull request #6798 (Add install-upgrade) and was stabilized in #7560 (Stabilize install-upgrade).

How does it work?

Instead of failing when cargo install detects a package is already installed, it will upgrade if the versions don't match, or do nothing (exit 0) if it is considered "up-to-date".

Forcing an upgrade / re-installation

The following command will always uninstall, download and compile the latest version of the crate - even if there's no newer version available. Under normal circumstances the install-upgrade feature should be preferred as it does save time and bandwidth if there's no new version of the crate.

cargo install --force <crate>

Documentation

Further information can be found in the GitHub issue rust-lang/cargo#6797 and in the official documentation chapter.

I believe that manifest file is just for the built-in libraries, i.e. those distributed with rustc. cargo itself stores things in ~/.cargo (for the moment), if you do wish to just remove all the libraries then deleting that directory won't break anything.

If you're just wanting cargo to rebuild/update dependencies you can run cargo update.

If you look at the documentation for configuring Cargo, you'll note there is an index key in the [registry] section. This can be any path to a Git repository.

As such, you can make a local clone of the crates.io index. I verified this by cloning it like so:

git clone --bare https://github.com/rust-lang/crates.io-index.git

then editing my Cargo configuration (specifically, I changed ~/.cargo/config, but this should work anywhere the documentation describes) to contain:

[registry]
index = "file:///F:/Data/Repositories/crates.io-index.git"

A few things to note:

1. This does not mirror the actual contents of the packages. Those come from a different host. I do not know how to mirror those, however: Cargo is much better about caching those locally. It should be enough to cargo fetch packages, then copy the cached *.crate files in $HOME/.cargo/registry/cache/*.

2. This causes the package identifiers in your Cargo.lock file to change. This isn't a problem for developing libraries, but it does become a problem for binaries. Standard practice is to check your Cargo.lock into source control for binaries so that everyone downstream builds with the exact same package versions. However, the modified index means no one else will be able to build the package with that lock file in place.

   I've worked around this by placing another config override within binary packages that resets the index to the "official" one, but that may not even be possible in your situation. In that case, you may need to either exclude Cargo.lock from source control, or just have a "doesn't use the official index" branch.