Implement --explicit-version from standalone cargo-vendor. This helps with
vendoring performance as it avoids redundantly deleting and re-copying
already vendored packages.
For example, when re-vendoring cargo's dependencies it makes a big
improvement on wallclock time. For initial vendoring it makes no
difference, but re-vendoring (ie, when most or all dependencies haven't
changed) without explicit versions is actually slightly slower (5.8s ->
6s), but with explicit versions it goes from 5.8s -> 1.6s.
Timings:
Without explicit versions, initial vendor
real 0m5.810s
user 0m0.924s
sys 0m2.491s
Re-vendor:
real 0m6.083s
user 0m0.937s
sys 0m2.654s
With explicit versions, initial vendor:
real 0m5.810s
user 0m0.937s
sys 0m2.461s
Re-vendor:
real 0m1.567s
user 0m0.578s
sys 0m0.967s
The summaries of syscalls executed shows why:
Revendoring without explicit versions:
```
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
25.17 1.104699 18 59432 1065 openat
19.86 0.871574 21 41156 13825 unlink
13.64 0.598739 2 210510 lstat
9.02 0.395948 29 13208 copy_file_range
8.00 0.351242 11 30245 read
6.36 0.279005 3 72487 4476 statx
5.35 0.235027 6 37219 write
4.02 0.176267 3 58368 close
```
with explicit versions:
```
29.38 0.419068 15 27798 13825 unlink
25.52 0.364021 1 209586 lstat
20.67 0.294788 16 17967 1032 openat
10.42 0.148586 4 35646 write
3.53 0.050350 3 13825 chmod
3.14 0.044786 2 16701 1622 statx
2.19 0.031171 1 16936 close
1.86 0.026538 24 1078 rmdir
```
Specifically, there are a lot fewer opens, copy_file_ranges, and unlinks.
This commit imports the external [alexcrichton/cargo-vendor
repository][repo] into Cargo itself. This means it will no longer be
necessary to install the `cargo-vendor` subcommand in order to vendor
dependencies. Additionally it'll always support the latest feature set
of Cargo as it'll be built into Cargo!
All tests were imported as part of this commit, but not all features
were imported. Some flags have been left out that were added later in
the lifetime of `cargo vendor` which seem like they're more questionable
to stabilize. I'm hoping that they can have separate PRs adding their
implementation here, and we can make a decision of their stabilization
at a later date.
The current man page for `cargo vendor -h` will look like:
cargo-vendor
Vendor all dependencies for a project locally
USAGE:
cargo vendor [OPTIONS] [--] [path]
OPTIONS:
-q, --quiet No output printed to stdout
--manifest-path <PATH> Path to Cargo.toml
--no-delete Don't delete older crates in the vendor directory
-s, --sync <TOML>... Additional `Cargo.toml` to sync and vendor
--respect-source-config Respect `[source]` config in `.cargo/config`
-v, --verbose Use verbose output (-vv very verbose/build.rs output)
--color <WHEN> Coloring: auto, always, never
--frozen Require Cargo.lock and cache are up to date
--locked Require Cargo.lock is up to date
-Z <FLAG>... Unstable (nightly-only) flags to Cargo, see 'cargo -Z help' for details
-h, --help Prints help information
ARGS:
<path> Where to vendor crates (`vendor` by default)
This cargo subcommand will vendor all crates.io and git dependencies for a
project into the specified directory at `<path>`. After this command completes
the vendor directory specified by `<path>` will contain all remote sources from
dependencies specified. Additionally manifest beyond the default one can be
specified with the `-s` option.
The `cargo vendor` command will also print out the configuration necessary
to use the vendored sources, which when needed is then encoded into
`.cargo/config`.
Since this change is not importing 100% of the functionality of the
existing `cargo vendor` this change does run a risk of being a breaking
change for any folks using such functionality. Executing `cargo vendor`
will favor the built-in command rather than an external subcommand,
causing unimplemented features to become errors about flag usage.
[repo]: https://github.com/alexcrichton/cargo-vendor
