This is a proof-of-concept Cargo subcommand which is used to vendor all crates.io dependencies into a local directory.
Leveraging file://
URLs, this subcommand will construct a custom registry
index which only contains the necessary packages, cache all necessary crate
files, and then place everything in a structure that Cargo expects.
Currently this can be installed with:
$ git clone https://github.com/alexcrichton/cargo-vendor
$ cd cargo-vendor
$ cargo build --release
Then move the binary target/release/cargo-vendor
into your PATH
or add
target/release
to your PATH
.
First, cd
into a Cargo project's root directory, then run the following
command:
``
$ cargo vendor
Create a
.cargo/config` with this entry to use the vendor cache:
[registry]
index = "file:///home/foo/code/bar/vendor/index"
$ cargo build
Updating registry file:///home/foo/code/bar/vendor/index
Downloading rustc-serialize v0.3.16 (registry file:///home/foo/code/bar/vendor/index)
Compiling rustc-serialize v0.3.16 (registry file:///home/foo/code/bar/vendor/index)
Compiling ...
```
This will populate the vendor
directory (generating an error it if it already
exists) with the index for the "custom registry" as well as a copy of all the
crates needed. The configuration printed can be placed in any .cargo/config
to point your project at that index, and then all future builds will use that
index.
This uses the same mechanisms that Cargo actually uses to test its support for registry-based sources. Cargo primarily knows where to download crates from through a git repository called the index. The main crates.io index contains all the necessary information to download crates and learn about their dependencies.
All this information isn't needed for just one crate build though! This crate
will take your crate's Cargo.lock
and generate an index with the bare minimum
of information needed to build your crate. This custom index is stored in
vendor/index
if you'd like to poke around it.
You'll note a config.json
file at the root of the index itself, and the
notable part of this is the dl
key which indicates where crates are downloaded
from. This notably also uses the file://
protocol to specify the root location
where crates are "downloaded" from. This is currently vendor/download
, and
that location is populated with the downloaded .crate
file for all of your
dependencies.
After assembling these two locations, you can tell cargo to use a non-default
index via the registry.index
key in .cargo/config
. With all that set up
Cargo will talk to your local index and "download" files from it, never touching
the network!
Currently the Cargo.lock
will change depending on whether the index is
crates.io or the local vendor'd copy. This is not always desired and may
require the crates.io Cargo.lock
to be stored next to the vendor'd
Cargo.lock
.
Updating dependencies currently requires going back to the crates.io
Cargo.lock
and then re-vendoring all dependencies.
The vendor directory may not be suitable for checking into a VCS as it contains a git repo itself and also contains tarballs, not checked out contents.
cargo-vendor
is primarily distributed under the terms of both the MIT license
and the Apache License (Version 2.0), with portions covered by various BSD-like
licenses.
See LICENSE-APACHE, and LICENSE-MIT for details.