Allowing "-"/"_" renaming on crates.io and treat them the same in Cargo.toml dependencies

[rustonaut]

I recently undusted a old crate of mine and published it to crates.io.
Through I made the mistake to forgot to rename "checked_command" to "checked-command"...
There is currently no good way to "fix" this as it is neither possible to publish it with the correct name ("-" instead of "_") nor can it be renamed. This makes sense to a certain degree, as renaming it would brake
dependencies.

I think it would be good if:

1. cargo+crates.io treat "-" and "_" as the same character in all places, including the dependencies field
2. if 1. is implemented renaming "-" to "_" can be added

This can also be helpful for some old crates published when using "-" wasn't the way to go.
It would also make it slightly nicer for new users as they can place the same name
in the [dependencies] section they use with extern crate.

[sgrif]

If we were to do something like this, it would almost certainly need an RFC as it affects cargo as well as crates.io

[rustonaut]

I think I will open a discussion in the internals forum first ;=)
The reason it ended up here was because I hoped there might some "quick fix",
and changes to crates.io/cargo would be more like a long term solution

[carols10cents]

Link to internals discussion: https://internals.rust-lang.org/t/maybe-pre-rfc-improving---in-cargo-crates-io/5251/11

[carols10cents]

I'm confused, if - and _ are treated the same everywhere (assuming it's possible), then why is renaming needed at all?

[rustonaut]

I was approaching this problem from the angle that I would like to rename a some_crate named crate to some-crate.

I agree that one _ and - are treated the same there is no reason to allow renaming (expect to change what is displayed as crate name in crates.io, but then renaming(-/_ only) would break thinks for people using a older cargo version and wouldn't be worth it).

Also by now the main reason why this features would be nice to have is general usability, especially for new people which might read extern some_crate and wonder why using some_crate in Cargo.toml won't work (and everyone frequently looking up if some crate was now named with _ or - ;=) )

[webmaster128]

Our motivation is the other way round: we have cosmwasm-vm published and want to rename to cosmwasm_vm on order to have the same spelling on crates.io and in the imports.

[obi1kenobi]

I seem to have run into a particularly unfortunate combination of edge cases here, with the end result that I have locked myself out of making the cargo plugin with the name I wanted.

My unfortunate steps:

• I wanted to make a cargo plugin, cargo-semver-check.
• I accidentally added a [lib] block into Cargo.toml, and got the following error:

error: failed to parse manifest at `.../Cargo.toml`

Caused by:
  library target names cannot contain hyphens: cargo-semver-check

• Without thinking hard enough, I replaced the hyphens with underscores everywhere (because, I thought, "it shouldn't matter"), renaming my crate to cargo_semver_check and publishing a placeholder to reserve the name while I worked on the content.
• Eventually, I realized that I wanted an application and not a library crate, and removed the [lib] block.
• I then ran cargo install cargo_semver_check and was surprised to see that neither of cargo semver-check and cargo semver_check worked.
• I then tried to rename my crate to cargo-semver-check so I can use it with cargo ... and here I am now 😢
• If there is a way to make cargo_semver_check work with cargo, I have not found it. This is of course secondary to the actual best-case scenario of renaming the crate.

I completely understand the reasons why renaming crates is not allowed. However, it also seems like the particular predicament I'm in (100% by my own fault, to be clear) is undesirable.

As one example, perhaps crates.io and/or cargo could warn about and/or reject crate names that simultaneously contain underscores and start with cargo_?

[CAD97]

If there is a way to make cargo_semver_check work with cargo, I have not found it.

(replying here for lack of a better plan)

Keep the [package].name as cargo_semver_check but set the [[bin]].name to cargo-semver-check. You may need to set [[bin]].path to src/main.rs as well as [package].autobins = false to avoid double builds.

(I'd also like to (re?) second just entirely removing everything which cares about [-_] in [package].name; crates-io would then display whatever the [package].name of the displayed version is, and perhaps a little ⚠️ note that the package name has changed from some_crate to some-crate. If the crates-io team has bandwidth (IIRC they don't) I'd be happy to write up a high-level spec¹ for the behavior here.)

Footnotes

1. Notably, the package name in the registry need not and should not change, but remain as whatever the originally published package name was, to avoid breaking older cargos. The behavior change should in theory be localized to 1) new cargos do a [-_] insensitive package lookup, 2) publishing a package which differs only in [-_] publishes to the original package, 3) search on crates-io is [-_] insensitive, 4) crates-io crate URLs are [-_] insensitive, and 5) crates-io displays the [package].name as-is for the shown version, along with an optional warning note if it differs from the name in the registry. ↩

[obi1kenobi]

Thanks. It's a reasonable workaround. I just don't think it's for me.

In the end, I decided that the risk of confusion was too great, and just renamed and republished the crate as cargo-semver-checks instead. It's less good of a name, and I don't like it, but I like it better than installing cargo_semver_check to run a binary called cargo-semver-check, executed as cargo semver-check. The - vs _ would inevitably get confusing for me, and I wanted to avoid it altogether. It's sad, but I understand why things are this way and I empathize with the lack of bandwidth for the crates-io and cargo teams — they carry a heavy load already.