cargo install --git finds binaries in crates that are not part of the root workspace

[lopopolo]

Problem

When running cargo install with a git repository, cargo finds bin targets in all crates in the repository, even if they are not part of the root workspace.

artichoke/artichoke declares a Cargo.toml workspace like:

[workspace]
members = [
  "artichoke-backend",
  "artichoke-core",
  "scolapasta-hex",
  "scolapasta-string-escape",
  "spinoso-array",
  "spinoso-env",
  "spinoso-exception",
  "spinoso-math",
  "spinoso-random",
  "spinoso-securerandom",
  "spinoso-symbol",
  "spinoso-time",
]

The workspace is not virtual. There is a root crate that has two bin targets. These bin targets are the only binaries built by this root workspace.

Both artichoke-fuzz and spec-runner are crates at the top-level of the repository, but are not part of the root workspace. These crates declare they are the sole member of a subworkspace with:

# `spec-runner` is a regression testing tool
# Remove it from the main artichoke workspace.
[workspace]
members = ["."]

I would expect to be able to run cargo install --git https://github.com/artichoke/artichoke --branch trunk without specifying a target crate, since the root workspace only has one crate with bin targets.

Steps

$ cargo install --git https://github.com/artichoke/artichoke --branch trunk
    Updating git repository `https://github.com/artichoke/artichoke`
error: multiple packages with binaries found: artichoke, artichoke-fuzz, spec-runner

Possible Solution(s)

Notes

Output of cargo version:

$ cargo -Vv
cargo 1.48.0 (65cbdd2dc 2020-10-14)
release: 1.48.0
commit-hash: 65cbdd2dc0b7e877577474b98b7d071308d0bb6f
commit-date: 2020-10-14

[alexcrichton]

This is an intentional design decision of cargo install because git repositories can host multiple packages. We could improve the error message, however, and recommend -p options perhaps, though.

[lopopolo]

@alexcrichton Can you clarify what you mean by "this" is a design decision?

Do you mean: cargo intentionally finds all bin targets in a repository regardless of the workspace configuration in the Cargo.toml in the root of the repository.

[lopopolo]

This behavior is different than, e.g. cargo build, where -p respects the workspace.members configuration.

cargo build

$ git remote get-url origin
[email protected]:artichoke/artichoke.git
$ pwd
/Users/lopopolo/dev/artichoke/artichoke
$ cargo build -p spec-runner
error: package ID specification `spec-runner` matched no packages

cargo install

$ cargo install --git https://github.com/artichoke/artichoke --branch trunk --locked spec-runner
    Updating git repository `https://github.com/artichoke/artichoke`
  Installing spec-runner v0.3.0 (https://github.com/artichoke/artichoke?branch=trunk#1c02dee8)
    Updating crates.io index
   Compiling memchr v2.3.4
   Compiling libc v0.2.81
   Compiling autocfg v1.0.1
   Compiling proc-macro2 v1.0.24
   Compiling version_check v0.9.2
   Compiling unicode-xid v0.2.1
   Compiling bitflags v1.2.1
   Compiling lazy_static v1.4.0
   Compiling regex-syntax v0.6.21
   Compiling syn v1.0.55
   Compiling getrandom v0.1.15
   Compiling glob v0.3.0
   Compiling cc v1.0.66
   Compiling cfg-if v0.1.10
   Compiling target-lexicon v0.11.1
   Compiling pkg-config v0.3.19
   Compiling cfg-if v1.0.0
   Compiling ppv-lite86 v0.2.10
   Compiling bindgen v0.56.0
   Compiling libm v0.2.1
   Compiling lazycell v1.3.0
   Compiling peeking_take_while v0.1.2
   # snip ...

[alexcrichton]

Yeah Cargo will walk the entire git repository looking for crates and determine the set of packages with binaries from that walk. Currently cargo install doesn't respect workspaces (IIRC it predates workspaces), and unfortunately changing that may be a breaking change. We could perhaps brainstorm an opt-in solution, however.