If you depend on a binary then commands are inconsistent

[Eh2406]

For example if you have

[dependencies]
wasm-bindgen-cli = "=0.2.48"

Then cargo tree will list all and cargo vender will download all of wasm-bindgen-cli's depenacys. But cargo metadata will list none, and cargo check will only build some of them. So this is a mess, and clearly needs to be made more consistent.

Previous discussion at: https://rust-lang.zulipchat.com/#narrow/stream/246057-t-cargo/topic/Differences.20between.20tree.20and.20metadata.20commands

[UebelAndre]

I'm very interested in knowing what the intended/expected behavior is here so I can align myself with that expectation.

[ehuss]

Binary-only dependencies aren't supported right now, so I think the expectation is that "it doesn't work". #4316 is a feature request for that, and adding support would require an RFC.

#4226 is open for improving the error messages. I lean towards Cargo should issue a warning that you have an invalid dependency (probably should only warn for immediate dependencies?). But I'm sometimes hesitant to add warnings, since Cargo doesn't have a silencing mechanism, and they can generally be annoying.

I would personally not bother trying to make vendor or tree do anything different, and just add a warning.

[UebelAndre]

"Not supported right now" would set the expectation to be "doesn't work right now" but doesn't say anything about intent. Are binary dependencies something that makes sense and would one day be supported? This kind of info is more what I'm after. For now, I'm looking for some mild confirmation that there's no plans to support that until an RFC is drafted and ultimately approved, which I think I just got, so I think I have the answer to that.

As for the behavior of all these commands, I think there should be a warning of the existence of binary dependencies and that all commands should have the same behavior since that seems to be the intent.

[ehuss]

I think there is a general agreement that it could be useful. What is not clear is exactly what it means to depend on a binary. There are multiple use cases, such as:

• Embedding the contents of another Cargo-based program within your crate.
• Running another executable at build time.
• Installing a local command-line tool that is scoped to the project.
• Including executables from packages outside of the workspace in the output directory.

And it could potentially also have some overlap with something like Swift's binary dependencies.

It's also not clear if these use cases could be better served by a general-purpose build tool (which can build/install executables from any language or build system).

I don't know if there was ever any intent to support or not support it. Given that it is mostly broken now (and has never worked), a warning would probably help those who stumble on it.

[UebelAndre]

@ehuss Hey, friendly ping for any updates here 🙏 😅

[Eh2406]

rust-lang/rfcs#3028