Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
rustonaut opened this issue May 16, 2017 · 10 comments
Labels
A-publish C-enhancement ✨ Category: Adding new behavior or a change to the way an existing feature works

Comments

@rustonaut
Copy link

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
Copy link
Contributor

sgrif commented May 16, 2017

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
Copy link
Author

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
Copy link
Member

@carols10cents
Copy link
Member

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

@rustonaut
Copy link
Author

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
Copy link

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
Copy link
Member

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
Copy link

CAD97 commented Jul 21, 2022

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 spec1 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
Copy link
Member

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.

@Turbo87
Copy link
Member

Turbo87 commented Jul 17, 2024

rust-lang/rfcs#3660 proposes a way for crate authors to delete their crates (and then be able to reregister them, potentially with underscores instead of hyphens or vice-versa).

It seems unlikely at this point that crates.io and cargo will implement such a breaking change of allowing renames, since the whole ecosystem is expecting us to work a certain way and changing it could have various unintended side effects.

If you would like the ability to rename your packages then I would recommend reviewing the RFC and supporting it to move it forward.

@Turbo87 Turbo87 closed this as not planned Won't fix, can't repro, duplicate, stale Jul 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-publish C-enhancement ✨ Category: Adding new behavior or a change to the way an existing feature works
Projects
None yet
Development

No branches or pull requests

7 participants