Error for `cargo run --bin {name}` should notice multiple packages have the same binary name

[workingjubilee]

Problem

$ cargo run --bin strings/pgrx_embed
error: no bin target named `strings/pgrx_embed`.
Available bin targets:
    pgrx_embed
    pgrx_embed
    pgrx_embed
    pgrx_embed
    pgrx_embed
    cargo-pgrx
    pgrx_embed
    pgrx_embed
    pgrx_embed
    pgrx_embed
    pgrx_embed
    pgrx_embed
    pgrx_embed
    pgrx_embed
    pgrx_embed
    pgrx_embed
    pgrx-version-updater
    pgrx_embed
    pgrx_embed
    pgrx_embed
    pgrx_embed
    pgrx_embed
    pgrx_embed
    pgrx_embed
    pgrx_embed
    pgrx_embed
    pgrx_embed
    pgrx_embed

This is obviously bad UX, as users can even now address these individual binaries in individual packages, despite having the same name, by using e.g. cargo run -p strings --bin pgrx_embed.

Proposed Solution

While I am reconsidering the UX in this proposed changed to pgrx's tooling which would involve this diff, I would like it if cargo was able to distinguish binaries in different packages with the same name and at least emit a more useful error message.

Notes

The reason for having a binary of the same name for all these packages is that several other "tooling is bad for this" problems are being worked around by various means, and this is one of the proposed workarounds that is better than other workarounds. The current workarounds involve dlopening a Rust programmer's cdylib in order to generate SQL based on the programmer's Rust code, this one would generate a binary that knows how to emit the SQL. This could all be omitted if Rust tooling simply had a more advanced facility for emitting user-defined metadata so that we could organize it later.

[epage]

Sounds like you are suggesting a shorthand for specifying the bin and package at the same time, something like:

$ cargo run --bin jkjlkjkljjljkkl
error: no bin target named `jkjlkjkljjljkkl`.
Available bin targets:
    foo/pgrx_embed
    bar/pgrx_embed
...

Without adding new syntax, we could also likely just add more context like either

$ cargo run --bin jkjlkjkljjljkkl
error: no bin target named `jkjlkjkljjljkkl`.
Available bin targets:
    -p foo --bin pgrx_embed
    -p bar --bin pgrx_embed
...

or

$ cargo run --bin jkjlkjkljjljkkl
error: no bin target named `jkjlkjkljjljkkl`.
Available bin targets from package foo:
    pgrx_embed
Available bin targets from package bar:
    pgrx_embed
...

[epage]

This could all be omitted if Rust tooling simply had a more advanced facility for emitting user-defined metadata so that we could organize it later.

Trying to see if I understand this. Are you interested in proc-macros having access to an OUT_DIR, like build.rs files do?

[workingjubilee]

Sounds like you are suggesting a shorthand for specifying the bin and package at the same time, something like:

Hmm, I don't need a shorthand, that was just what I tried. Visibly disambiguating the dozen instances of the same binary name, when there is a way to disambiguate them, and informing the user on how to do that programmatically, is the key.

Trying to see if I understand this. Are you interested in proc-macros having access to an OUT_DIR, like build.rs files do?

Sure, that's one way to do it.

[epage]

For any consideration of fixing this, I want to note that this workflow can generate warnings / bad behavior:

$ cargo build
warning: virtual workspace defaulting to `resolver = "1"` despite one or more workspace members being on edition 2021
which implies `resolver = "2"`
note: to keep the current resolver, specify `workspace.resolver = "1"` in the workspace root's manifest
note: to use the edition 2021 resolver, specify `workspace.resolver = "2"` in the workspace root's manifest
note: for more details see https://doc.rust-lang.org/cargo/reference/resolver.html#resolver-versions
warning: output filename collision.
The bin target `foo` in package `foo2 v0.1.0 (/home/epage/src/personal/dump/multi-bin/crates/foo2)` has the same outpu
t filename as the bin target `foo` in package `foo1 v0.1.0 (/home/epage/src/personal/dump/multi-bin/crates/foo1)`.
Colliding filename is: /home/epage/src/personal/dump/multi-bin/target/debug/foo
The targets should have unique names.
Consider changing their names to be unique or compiling them separately.
This may become a hard error in the future; see <https://github.com/rust-lang/cargo/issues/6313>.
warning: output filename collision.
The bin target `foo` in package `foo2 v0.1.0 (/home/epage/src/personal/dump/multi-bin/crates/foo2)` has the same outpu
t filename as the bin target `foo` in package `foo1 v0.1.0 (/home/epage/src/personal/dump/multi-bin/crates/foo1)`.
Colliding filename is: /home/epage/src/personal/dump/multi-bin/target/debug/foo.dwp
The targets should have unique names.
Consider changing their names to be unique or compiling them separately.
This may become a hard error in the future; see <https://github.com/rust-lang/cargo/issues/6313>.
warning: output filename collision.
The bin target `foo` in package `foo3 v0.1.0 (/home/epage/src/personal/dump/multi-bin/crates/foo3)` has the same outpu
t filename as the bin target `foo` in package `foo2 v0.1.0 (/home/epage/src/personal/dump/multi-bin/crates/foo2)`.
Colliding filename is: /home/epage/src/personal/dump/multi-bin/target/debug/foo
The targets should have unique names.
Consider changing their names to be unique or compiling them separately.
This may become a hard error in the future; see <https://github.com/rust-lang/cargo/issues/6313>.
warning: output filename collision.
The bin target `foo` in package `foo3 v0.1.0 (/home/epage/src/personal/dump/multi-bin/crates/foo3)` has the same outpu
t filename as the bin target `foo` in package `foo2 v0.1.0 (/home/epage/src/personal/dump/multi-bin/crates/foo2)`.
Colliding filename is: /home/epage/src/personal/dump/multi-bin/target/debug/foo.dwp
The targets should have unique names.
Consider changing their names to be unique or compiling them separately.
This may become a hard error in the future; see <https://github.com/rust-lang/cargo/issues/6313>.
   Compiling foo1 v0.1.0 (/home/epage/src/personal/dump/multi-bin/crates/foo1)
   Compiling foo3 v0.1.0 (/home/epage/src/personal/dump/multi-bin/crates/foo3)
   Compiling foo2 v0.1.0 (/home/epage/src/personal/dump/multi-bin/crates/foo2)
    Finished dev [unoptimized + debuginfo] target(s) in 0.17s

[workingjubilee]

@ehuss Thanks for letting me know! That's useful information.

This definitely aggravates my desire to have a directory that I can emit metadata into during proc macro execution, without having to worry so much about collisions. I don't know if that's already available somehow or what.

[workingjubilee]

My current plan is to concatenate the package name and an affix for the binary to generate the format!("src/bin/{binary_name}.rs") we write to, and to prevent this from being hard-coded (rather than merely initialized-as-such) by writing a [package.metadata.pgrx] table to Cargo.toml. I hope that won't cause too much havoc.