The --bin flag on the install subcommand doesn't work

[RazrFalcon]

% cargo install --force --bin svgcleaner --git https://github.com/RazrFalcon/svgcleaner               
    Updating git repository `https://github.com/RazrFalcon/svgcleaner`
error: multiple packages with binaries found: docgen, files-testing, stats, svgcleaner, use_as_lib

% cargo -V
cargo 0.23.0 (61fa02415 2017-11-22)

[ishanjain28]

All the packages are installed using install function in src/cargo/ops/cargo_install.rs. This function takes a krate: Vec<&str> which is created from options.arg_crate in execute function in src/bin/install.rs.

In the command,

cargo install --force --bin svgcleaner --git https://github.com/RazrFalcon/svgcleaner               

options.arg_crate is an empty vector. The value of --bin flag(svgcleaner) is used to generate CompileFilter but never used. So, You are getting this error.

@RazrFalcon,
For your case, You can use cargo install --force svgcleaner --git https://github.com/RazrFalcon/svgcleaner and it'll work just fine. I'll try to send a PR to fix this before Monday.

[RazrFalcon]

@ishanjain28 thanks, that worked.

[kornelski]

I've ran into the same problem:

cargo install --bin cargo-deb --git https://github.com/mmstick/cargo-deb --force
    Updating git repository `https://github.com/mmstick/cargo-deb`
error: multiple packages with binaries found: cargo-deb, example

I see from this issue that skipping --bin solves the problem. However, I wouldn't have figured it out myself, because:

• I assumed cargo install foo refers to foo on crates.io only, and --git foo is a replacement for the package name, not an independent argument.
• Other cargo commands use -p to select the package, but not this one.
• cargo install --help shows cargo install [OPTIONS] [--] [crate]... says crate, but the error is about packages.
• cargo install --help has "--bin ... Install only the specified binary" which sounded exactly like what I wanted.

Things that could help:

• Add help text to the error message suggesting adding crate name as the first arg
• When --bin is specified, but not the crate/package, either search all of them, or show an error explaining specifically why --bin was ignored.
• Support -p, --package to specify the package for consistency with other commands.

[teor2345]

Just copying those suggestions here:

1. --bin zebrad should install the binary with that name, if there are multiple packages with binaries
2. --bins should install all binaries, if there are multiple packages with binaries
3. if there is only one binary in the workspace default-members, that binary should be installed
4. a multiple packages with binaries found error should give users a hint about how to specify a single crate

[teor2345]

Here's another possible solution:
5. add a default-install key to the package section of the manifest, which acts like default-run

default-run configures the default binary for cargo run, where:

• there are multiple binaries in a crate, default-run is set in the crate Cargo.toml, and cargo run is run in the crate directory, or
• there are multiple binaries in a workspace, default-run is set in exactly one crate's Cargo.toml, and cargo run is run in the workspace directory

This second behaviour was a bit surprising, but I think it's actually a good thing.

[dpurfield]

I’m new to rust but my understanding is a package (cargo.toml) can have multiple crates in the form of 1 library and/or multiple binaries. (ref: The Book section 7.1 2nd paragraph). But crate is also used to refer to a published package on crates.io. And since a package can contain multiple binaries i would assume a published crate on crates.io can as well. So there is a conflict of what this term crate means.

The cargo install command help is incorrect in that it states the default arg is a crate. If you are installing a crate from crates.io this is true. But if you calling install with either —path or —git option the default arg is actually a package. I’m referring to this being a package since it is referring to the name property inside a cargo.toml file, not a published crate. Additionally the error messages such as the “multiple package error” in the original post refer to it as a package not a crate.

cargo install —help:
--git Git URL to install the specified crate from
--path Filesystem path to local crate to install
…
ARGS:
< crate>...

When using the path option, the path must point to the folder with the package. So a package is not required, as there can only be one cargo.toml per folder. But if provided, the package most match the name of the one in the path provided.

When using the git option, the package is required only when there are multiple packages in the repo. It will not default to the root package. And a path can not be provided with a git option to point to a subfolder containing a package.

I would like to do the following if its agreed as valid solution:
1.) change the help to name the default ARGS from < crate> to <crate(s)/package(s)>.
2.) change the functionality of the git option to the following:
default to the only package with a binary or the root package
if there are multiple packages with binaries and none in the root folder then raise an error:
error: package is required when unable to find default package

[dpurfield]

I'm also good with any of the suggestions made in #8958.

[teor2345]

When using the path option, the path must point to the folder with the package. So a package is not required, as there can only be one cargo.toml per folder. But if provided, the package most match the name of the one in the path provided.

I think we've used --path with a workspace containing multiple library and binary packages. But I'd have to double-check how we made it work.