Enable 'cargo install' to install binary-crates according to a spec of dependencies

[avkonst]

Currently, workflow for rust developers is something like the following:

git clone ...
cd my_project
# part 1 of the workflow:
cargo install cargo-watch --ver 6.0.0
cargo install cargo-release
cargo install cargo-outdated --ver 0.7.0
cargo install .... # more installs of 3rd party extensions to enable automated management of a project
# part 2 of the workflow:
cargo build
cargo watch
cargo release
cargo outdated
cargo ... # more other commands

I noticed that new setup of a development machine or CI box requires consistent installation / synchronization of the required tools and their versions, which is part 1 of the workflow in the example above.
I have raised more detailed problem description here and it seems there was no a solution found.

I see that required tools and their versions are perfect match for dependencies specification in the Cargo.toml file. For example, cargo could support install-dependencies section, like the following:

[install-dependencies]
cargo-watch = "6.0.0"
cargo-outdated = "0.7.0"
.... and so on for all the tools mentioned in README docs for developers and required to manage a project

If it was available, the workflow could become something like this:

git clone ...
cd my_project
# part 1 of the workflow:
cargo install
# part 2 of the workflow:
cargo build
cargo watch
cargo release
cargo outdated
cargo ... # more other commands

Notice cargo install without arguments. It means cargo would read from the toml file and installs accordingly to install-dependencies. This gives 2 benefits:

1. solves the problem like: "readme tells run cargo release when you need to release, but there is no such cargo command available"
2. solves the problem like: "readme tells run cargo release when you need to release, but running it fails, because the currently installed version OR enabled features of the tool are too old or not compatible with the current version of a project or compiler version"

Having the above functionality (running cargo install without arguments) would bring cargo to be on par with npm install (note: yes, I know npm install also installs package and dev dependencies, but I am not suggesting this for cargo, hence new install-dependencies section is proposed for the toml file only for binary-crate tools).

However, cargo can do even better than npm in this area. cargo install could be invoked implicitly on the first run of unknown command. This way the workflow becomes as simple as this:

git clone ...
cd my_project
# part 1 of the workflow:
# nothing to do
# part 2 of the workflow:
cargo build
cargo watch
cargo release
cargo outdated
cargo ... # more other native, 3rd party commands or aliases

This way all commands, either cargo native or 3rd party or aliases, look the same, their source and nature are not that important anymore. All 3rd party tools and their compatible versions are declared by a project on per project basis and installed automatically on need basis (for example, once first unknown command is invoked).

[alexcrichton]

Thanks for the report! This sounds like a neat feature, albeit somewhat weighty in terms of design!

[stale]

As there hasn't been any activity here in over 6 months I've marked this as stale and if no further activity happens for 7 days I will close it.

I'm a bot so this may be in error! If this issue should remain open, could someone (the author, a team member, or any interested party) please comment to that effect?

The team would be especially grateful if such a comment included details such as:

• Is this still relevant?
• If so, what is blocking it?
• Is it known what could be done to help move this forward?

Thank you for contributing!

If you're reading this comment from the distant future, fear not if this was closed automatically. If you believe it's still an issue please leave a comment and a team member can reopen this issue. Opening a new issue is also acceptable!

[avkonst]

I am still interested in. My current workaround is having a shell script which installs all necessary stuff to enable project dev workflows. It should be finally tracked by cargo instead.

[luser]

I appreciate the sentiment here but this feels like trying to make cargo into a full-blown package manager which I don't think is reasonable.

[qwerty2501]

Hi.
I read here and related issues.

I am still interested in. My current workaround is having a shell script which installs all necessary stuff to enable project dev workflows. It should be finally tracked by cargo instead.

I'm worried about the same thing.
However, This feature may be a little too big.

I appreciate the sentiment here but this feels like trying to make cargo into a full-blown package manager which I don't think is reasonable.

I guess this feature should not be implemented when the rust lang team want cargo to provide minimum package manager feature.
It seems that this feature should be provide as third party tool like cargo plugin.

[Expurple]

Hi, I reported #12764. My use case is a little different: the binary crate is not a cargo plugin and I don't want to install it globally. See my issue. TL;DR I think that we should implement

cargo build --bin ... --from-dep ...
cargo run --from-dep ...
cargo install --bin ... --from-dep ...

in that order.

[epage]

See also #2267

[epage]

As the use case is the same as #2267, I'm closing in favor of that so we have one place for discussing solutions and coming to an agreement on the design.

[abhillman]

Related proposal #13359

[abhillman]

Hi. I read here and related issues.

I am still interested in. My current workaround is having a shell script which installs all necessary stuff to enable project dev workflows. It should be finally tracked by cargo instead.

I'm worried about the same thing. However, This feature may be a little too big.

I appreciate the sentiment here but this feels like trying to make cargo into a full-blown package manager which I don't think is reasonable.

I guess this feature should not be implemented when the rust lang team want cargo to provide minimum package manager feature. It seems that this feature should be provide as third party tool like cargo plugin.

Indeed, simplicity is a reasonable design concern. In that case, perhaps the trick is writing some documentation about how to configure cargo to accommodate.