Allow running "cargo install" in a workspace

[Keruspe]

I have a project that is split into several crates in the same workspace. Some of these crates enable certain features for some dependencies. When I run cargo build from the workspace level, all the subcrates are built and features are properly enabled for the project as a whole.
Now if I want to install those, I have to go into each crate, then run cargo install --path=., which triggers some rebuild for each crate even if I already have a clean release build.

I would love being able to run, at the workspace level, something like cargo install --path=. --all or cargo install --path=. --crates=foo,bar or cargo install --path=foo --path=bar or anything like that, which would trigger a single build for all the crates, and then proceed with the install

[kaimast]

I'm surprised this is not supported yet.

[jacobmischka]

It does seem strange that it's unsupported. I'm currently just manually copying the binaries from the workspace target dir to .cargo/bin or somewhere else in my PATH, but that really shouldn't be necessary.

[cbs228]

I propose that cargo-install adopt the --workspace flag to install an entire workspace at once. The tricky part will be the interaction with all the other options.

• --workspace MUST NOT be allowed in combination with crates from a registry. Only --path and --git support workspaces.

• cargo install --workspace … -- crate1 crate2 MUST install only crate1 and crate2 from the selected workspace. If no crates are specified, all crates are installed.

• --workspace SHOULD be silently allowed for crates which are not workspaces. cargo build --workspace works just fine on crates which are not workspaces.

• cargo install --workspace MAY be interpreted to mean "the current workspace—" i.e., per the output of cargo locate-project --workspace. It may be better to be explicit here and require cargo install --workspace --dir .

• The --features option SHOULD require the package-name/feature-name syntax as the documentation currently suggests it does.

• --bins and --examples SHOULD apply as they do for individual crates.

• The singular --bin and --example are trickier. Right now, trying to install a non-existing target is an error. Perhaps these options should not be allowed in conjunction with --workspace.

Did I miss anything?

In the meanwhile, nightly appears to have:

cargo build --release --workspace --out-dir somewhere/on/my/path

This may permit install-like behavior for workspaces. This does not use the cargo-install machinery. It won't register the crates for cargo install --list or permit future overwrites with cargo-install.

[ghost]

There seems to be a difference in behavior when installing a workspace binary from Git vs from a local tree? Where cargo install --git=URL works, cargo install --path=. doesn't.

• When the toplevel manifest is virtual, e.g. https://github.com/rust-lang/rust-analyzer, both cargo install --path=. and cargo install --path=. rust-analyzer throw

error: found a virtual manifest at `rust-analyzer/Cargo.toml` instead of a package manifest

• When the toplevel manifest is non-virtual, both cargo install --path=. and cargo install --path=. CRATE throw

error: there is nothing to install in `<TOPLEVEL CRATE>`, because it has no binaries
`cargo install` is only for installing programs, and can't be used with libraries.
To use a library crate, add it as a dependency in a Cargo project instead.

In both cases, cargo install --git=file://$(pwd) works; although, it seems to just scan the entire tree for Cargo manifests. In the following layout, if --bin isn't specified, it might just as well decide to install fuzz_targets binaries instead of crate-bin.

Cargo.toml
   [workspace]
   members = [".", "crate-bin"]
   default-members = ["crate-bin"]
src/
└── lib.rs
fuzz/
├── Cargo.toml
└── fuzz_targets/
crate-bin/
├── Cargo.toml
└── src/main.rs

Note that setting default-members = ["CRATE"] doesn't help in any of the mentioned cases.

[weihanglo]

Triage: Looks pretty similar to #4101.

[johnbchron]

Bumping this :)

[epage]

Closing in favor of #4101. If there is a meaningful distinction that we should keep this open instead, let us know!