Feature: Batch installation

[NobodyXu]

On CI, it is often desirable to install all binaries it depended on at once ASAP.

Currently, cargo-binstall has to be invoked multiple times for multiple binaries, which is sequential and wastes time doing repeated works like pulling from https://crates.io .

I propose a new interface for batch installation:

cargo-binstall --no-confirm --batch cargo-watch:8.1.0 cargo-binstall

[passcod]

Don't really need a flag for it, let's just support multiple crate names like cargo install does.

For the versions, we should use whatever syntax cargo add (the version that's going built-in) uses, so we're consistent with the rest.

[NobodyXu]

Don't really need a flag for it, let's just support multiple crate names like cargo install does.

For the versions, we should use whatever syntax cargo add (the version that's going built-in) uses, so we're consistent with the rest.

But how do we habdle --version flag?

[passcod]

Make it a conflict with multiple arguments, like cargo add (the cargo-edit version) does:

$ cargo add --vers 1.2.3 foo bar
Command failed due to unhandled error: Cannot specify multiple crates with path or git or vers

Similarly we'll need an exclusion for --manifest-path and the other overrides.

Eventually we could deprecate the --version syntax.

---

Cargo install tries to apply the same version to both crates, which is certainly a choice but I don't think makes much sense:

$ cargo install --version 1.2.3 foo bar
    Updating crates.io index
error: could not find `foo` in registry `crates-io` with version `=1.2.3`
error: could not find `bar` in registry `crates-io` with version `=1.2.3`
     Summary Failed to install foo, bar (see error(s) above).
error: some crates failed to install

---

cargo add (both the external and the built-in versions) also uses the name@version syntax, so that's how we'll go

[NobodyXu]

What about:

cargo install --version 1.2.3 foo [email protected]

Should we just quit when --version is used together with *@...?

[passcod]

That seems the most sensible. Like, yes, we could try to interpret it as [email protected] [email protected] but it's not very clear, so it's more consistent to always disable / mutually exclude the syntaxes. We can have a cool message like Did you mean [email protected] [email protected] ? in this particular case, to be helpful

[NobodyXu]

Another thing I worry about is the confirmation step.

Currently, cargo-binstall at least confirms twice for non-source installation, this would hinder the parallelism when we try to implement this feature.

[passcod]

If we fetch everything we need upfront, we can present a single confirmation step for everything needed, I think. Then it's two highly parallel sequences (before confirm, after confirm), which also streamlines the UX.

We lose the last confirm before writing the files, but I don't know that that's really necessary tbh. With the crates metadata we should already have the list of files we want to write, and we can even read the local upfront to see what we would overwrite.