Looks like when vendor directories are checked into a VCS there's been instances
where deleting a folder in the VCS doesn't fully delete the folder from the
filesystem. This can lead to [spurious errors][moz] that are difficult to debug.
To help handle this tweak directory sources to ignore empty directories or
directories with only dotfiles by default.
[moz]: https://bugzilla.mozilla.org/show_bug.cgi?id=1342292
cargo fails if it can't find optional dependencies, even if corresponding feature not enabled
I have a directory registry containing all the crate sources needed to build an application crate (for instance, ripgrep), and a `$CARGO_HOME/config` file that looks like this:
```toml
[source.crates-io]
replace-with = "dh-cargo-registry"
[source.dh-cargo-registry]
directory = "/usr/share/cargo/registry/"
```
When I attempt to build ripgrep via "cargo install ripgrep" from that directory registry, I get this error:
```
error: failed to compile `ripgrep v0.3.1`, intermediate artifacts can be found at `/tmp/cargo-install.rmKApOw9BwAL`
Caused by:
no matching package named `simd` found (required by `bytecount`)
location searched: registry https://github.com/rust-lang/crates.io-index
version required: ^0.1.1
```
The directory registry indeed does not contain "simd"; however, bytecount doesn't require simd. It has an optional dependency on simd, and nothing enables the feature that requires that dependency.
Placing the simd crate sources into the directory registry allows ripgrep to build; the resulting build does not actually build the simd crate.
I can reproduce this by just trying to build the "bytecount" crate directly, using the same `$CARGO_HOME`:
```
error: no matching package named `simd` found (required by `bytecount`)
location searched: registry https://github.com/rust-lang/crates.io-index
version required: = 0.1.1
```
(Incidentally, that "version required" seems wrong: bytecount has an optional dependency on simd `^0.1.1`, not `=0.1.1`.)
However, this doesn't seem consistent with other crates in the same dependency tree. For instance, ripgrep also depends on clap, and clap has an optional dependency on yaml-rust, yet cargo does not complain about the missing yaml-rust.
I'd *guess* that the difference occurs because ripgrep has an optional feature `simd-accel` that depends on `bytecount/simd-accel`, so cargo wants to compute what packages it needs for that case too, even when building without that feature. (Similar to #3233.)
However, this makes it impossible to build a package while installing only the packaged dependencies for the enabled features. Could `cargo install` ignore any dependencies not actually required by the enabled feature? (That behavior would make no sense for "cargo build", which builds a Cargo.lock file that should remain consistent regardless of enabled features, but it makes sense for "cargo install cratename", which doesn't build a Cargo.lock file.)
When building with a directory registry that contains only the subset of
crates required to build an application crate, cargo fails if that
subset doesn't include optional dependencies pulled in for every
possible feature of the root crate, even when the install doesn't enable
those features. This prevents Linux distributions from building with
a minimal set of dependencies (omitting, for instance, packages for
unstable/nightly features).
Introduce a new workspace flag "require_optional_deps", disabled for
install and enabled for everything else. Skip the initial
Method::Everything resolve in this case, and modify
resolve_with_previous to support running a Method::Required resolve
without a previous resolution.
This also skips adding path overrides, as those won't make sense (and
won't work) for an install directly from a registry.
Introduce a set of tests for "cargo install" directly from a directory
registry.
This flavor of source is intended to behave like a local registry except that
its contents are unpacked rather than zipped up in `.crate` form. Like with
local registries the only way to use this currently is via the
`.cargo/config`-based source replacement currently, and primarily only to
replace crates.io or other registries at the moment.
A directory source is simply a directory which has many `.crate` files unpacked
inside of it. The directory is not recursively traversed for changes, but rather
it is just required that all elements in the directory are themselves
directories of packages.
This format is more suitable for checking into source trees, and it still
provides guarantees around preventing modification of the original source from
the upstream copy. Each directory in the directory source is required to have a
`.cargo-checksum.json` file indicating the checksum it *would* have had if the
crate had come from the original source as well as all of the sha256 checksums
of all the files in the repo. It is intended that directory sources are
assembled from a separately shipped subcommand (e.g. `cargo vendor` or `cargo
local-registry`), so these checksum files don't have to be managed manually.
Modification of a directory source is not the intended purpose, and if a
modification is detected then the user is nudged towards solutions like
`[replace]` which are intended for overriding other sources and processing local
modifications.
