Add ability to rename a crate on crates.io

#1

I think it would be nice to have the ability to rename a crate on the crates.io.

We could have it done in the following way:

  1. Add a button to rename a crate.
  2. Perform the rename: make the crate be accessible by both new and old names but the old name will stay alive for only a month.
  3. Every time someone builds their app with this crate as a dependency, they will get a message from cargo that this crate is being renamed (or even perform this rename automatically?) and will not be accessible since dd.MM.YYYY hh:mm:ss TIMEZONE.
  4. After a month since rename, this crate will only be accessible by its new name and the old one could be used by others.

Doing this will lead to transparently named crates, the names of which will give you an idea of what the crate is doing immediately.

As a side option, we could also implement a button for “rename request” which could be used by one crate developers to ask others about renaming their crate. However, we must ensure nobody will abuse the service and the crate owner that way.

0 Likes

#2

Warning about renaming could be added as part of yank:

0 Likes

#3

This sounds as if it would create (at best) very confusing breakages for apps who depend on it and can go more than a month between builds. Web pages (recommendations, tutorials, StackOverflow answers etc) referring to the old name would also rot.

I don’t see how this “will lead to transparently named crates” any more than the current system does. I thought crates.io’s naming woes were generally accepted to be the unavoidable consequence of a flat namespace, which would still be the case.

0 Likes

#4

For security the old name would probably have to stay reserved forever. Otherwise someone could take it and serve new code to existing projects (unless the recycled crate is forced to start at higher semver version, but that would be weird for new projects using that name).

So given that the old name sticks around anyway, it’s possible to make it a “redirect” by having Cargo.toml:

name = "old"

[dependencies]
new = "1"

and lib.rs:

pub use new::*;

This, combined with yank that explains the rename, should be OK IMHO. Perhaps this informal pattern could be wrapped in a command that performs this all in one step.

3 Likes

#5

For ordermap to indexmap, we just declared the old one deprecated, but left it in place. Yanking would hide that information.

1 Like