Tracking Issue for different-binary-name

[ehuss]

Summary

Original issue: #1706
Implementation: #9627
Documentation: https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#different-binary-name

The different-binary-name feature allows setting binary output filenames that are separate from the crate name, and are not restricted to Rust identifiers.

Unresolved issues

• Consider other ways of specifying the setting. There is some concern that filename may be misleading, particularly if we decide to use it for libraries where there is a prefix/suffix added. Other options to consider:
  • file_stem, though this may also be confusing with library prefix/suffix.
  • Change name to not be restricted to identifiers, but if it is not an identifier, require a crate-name field.
• Consider supporting other targets, like cdylibs or static libs. This can get tricky if a library is also built as an rlib.
• Is using the filename the correct choice for CARGO_BIN_NAME? There is some concern that this is introducing some inconsistencies that can cause confusion (for example, --bin uses the name and not the filename). The actual executable name was chosen for CARGO_BIN_NAME since the use case for that was reflecting the executable name in things like clap help text. How much of a problem are these inconsistencies going to be?

Future extensions

N/A

About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.

[SoniEx2]

artifact_name?

[kornelski]

Current implementation uses filename, but libstd uses file_name with underscore: https://doc.rust-lang.org/stable/std/?search=filename

[getreu]

There is some concern that filename may be misleading, particularly if we decide to use it for libraries where there is a prefix/suffix added.

target_file_stem?

I tested this feature with tp-note and common Linux targets. It works well for me. Also cargo deb works.

Any chances to get this stabilized in the near future?
Edit: Milestone seems to be Rust 1.56.0: Update cargo by ehuss · Pull Request #88127 · rust-lang/rust

[dyc3]

I think that target_flie_stem or target_file_name would be the most appropriate name. However, I do think "name" makes more sense than "stem".

Could this be abused to hide malicious programs when installing a crate? Suppose a bin crate sets the target file name to chmod and a user cargo installs the crate. Depending on how the user has their PATH set up, the crate could take over all calls to chmod. Should we enforce some restrictions on what the file name can be?

Maybe:

• Prevent cargo install from succeeding if there is already a matching command already available in the PATH
• Enforce that the target file name be a substring of the crate name

[CobaltCause]

• Prevent cargo install from succeeding if there is already a matching command already available in the PATH

I'm not a fan of this because it's "impure"; two invocations of cargo install might not work the same across computers.

• Enforce that the target file name be a substring of the crate name

I think this is still abusable because one could, for example, release a malicious cargo plugin named something like cargo-cool-plugin that renames itself to cargo, which is undesirable.

---

Instead of either of these, I suggest simply enforcing nothing but instead printing out the names of the commands added to PATH at the end of cargo install. This gives people freedom to choose whatever name they might want (maybe they do want to replace chmod) but also informs the user that the name might not be what they expect.

[CobaltCause]

Also, I suggest bin-name for the name of the configuration option, this seems more consistent with existing things like CARGO_BIN_NAME as noted in the issue description.