A way to execute local dependencies

[Expurple]

Problem

My project has a dependency (sea-orm), which I use both as a library and as a binary that I need to run (sea-orm-cli). This is a common use case for that dependency. The authors recommend cargo installing the binary globally, but this method has multiple disadvantages, because the binary's version is not tracked by my Cargo.toml and goes out of sync with the library. This becomes especially inconvenient when I need to work on multiple branches or multiple projects that use different versions of that dependency. I want the binary to be local and versioned by my Cargo.toml.

I started a discussion in the sea-orm repo. The authors suggest building my own executable which would act exactly like sea-orm-cli by running its exported function. This workaround solves the initial issue, but it still feels hacky and inconvenient. I would like if cargo supported this natively. From what I understand, currently there's no way to get it to build the upsteam binary.

Proposed Solution

Add an option like --from-crate, so that I can cargo build and cargo run a binary from a local dependency:

cargo run --bin sea-orm-cli --from-crate sea-orm-cli

For the initial implementation, cargo build would be enough. I can run the binary manually.

The name of the option is discussable, it can also be something like --crate, --from-dep, etc.

Notes

Essentially, I want npx, but for cargo.

[epage]

See also #5120

We'd likely need #9096

[Expurple]

RFC 3028 doesn't seem to cover my use case very well. I use sea-orm-cli as a code generator while writing code. I don't necessarily want to build my crate every time I run sea-orm-cli. But the RFC is only concerned with build time execution:

Note that cargo only supplies these dependencies when building your crate. If your program or library requires artifacts at runtime, you will still need to handle that yourself by some other means. Runtime requirements for installed crates are out of scope for this change.

---

#5120 seems to be only concerned with cargo commands. They want either an install step or magical detection of cargo subcommands in Cargo.toml, because that allows them to use the usual cargo plugin syntax: cargo something. I don't really need that, I'd be OK with cargo run --from-crate cargo-something. Actually, I'm kinda against the mandatory global install. We can implement everything in this order:

1. cargo build --from-crate

   This is the most important part: building binary dependencies locally. Having this, we can already run them manually as ./target/cargo-something/cargo-something. At this stage, if someone really needs a nice cargo something experience, they can make a script that creates symlinks in PATH. This is already better than the current situation, because the versions and features in Cargo.toml are always respected, the script doesn't need to hardcode its own versions.

2. cargo run --from-crate

   This entirely covers my use case with sea-orm-cli and allows to run local cargo plugins as cargo run --from-crate cargo-something.

3. cargo install --from-crate

   This allows to run local cargo plugins as cargo something after the install.

[epage]

I mentioned RFC 3028 because right now, cargo only officially supports depending on lib's and that RFC adds support for depending on bin's.

[Expurple]

All right, it makes sense to first get cargo to parse bin dependencies and build them under that RFC. And later add the capability to trigger the build differently

[ehuss]

I think this is also covered by #2267, which is also requesting the ability to cargo run a dependency. There is potentially some noise there, since there might be different use cases like having executables that are specifically for building, but it is also generally applicable to project-specific developer tools (diesel_cli is also a similar example). There is also more context at rust-lang/rfcs#3168.

Closing as a duplicate of #2267. If there are specific use cases that don't seem to be commented on in that issue, I'd suggest sharing them over there.