Change a published crate's canonincal name from hyphen to underscore or vice versa (once cargo recognizes either)

[Fraser999]

I mistakenly published a crate with a trailing _sys in its name instead of -sys. I can't now publish under the correct name as this is identified as a rename which is forbidden.

The ideal situation would be to rename the _sys crate, but failing that, is it possible to delete it and republish under the correct name?

The crate in question is https://crates.io/crates/maidsafe_libsodium_sys.

This relates to https://internals.rust-lang.org/t/pre-rfc-hyphens-in-crate-names-redux/1655. If that RFC were accepted and implemented, this wouldn't be an issue I guess?

[alexcrichton]

I can delete crates manually (allowing a re-publishing), but I do agree it would be nice to have the ability to do this automatically in some whitelisted scenarios.

Feel free to reach out to me on IRC (acrichto) if you want me to delete the crate to allow a republish.

[aidanhs]

This would also be useful for trying out releasing without permanently polluting crates.io (exposing the staging crates.io index somewhere for use with cargo publish --host would also work I think - I couldn't see it anywhere).

[ducks]

Did anyone have more thoughts on how this would work?

How does the --host thing sound? Maybe a --dry-run type flag that does everything up to the upload point? And I've never actually published a crate but is there a confirmation before pushing it up?

[Kerollmops]

up someone ? I have published some crates that doesn't work and was renamed.

[ostrokach]

I ran into this problem too. I pushed a bunch of packages to crates.io before realizing that it'd be more useful if they were combined into a single package. I ended up yanking those packages, but they still show up on my dashboard.

Would it be possible to add an option to permanently delete packages which don't have other packages depending on them? This would prevent packages that you require from randomly being pulled from crates.io, but would allow people starting out to delete / rename their packages at will?

[carols10cents]

Would it be possible to add an option to permanently delete packages which don't have other packages depending on them?

The packages that depend on the yanked crates might not be on crates.io :(

@alexcrichton wdym you delete people's crates from the database for them?!?!? doesn't this break reproducible builds????

I think NPM's current policy is to only allow deletion within 24 hours of publishing... I'm checking on that.

Rename... I could see a case for leaving the old crate where it is for install purposes, but allowing someone to change the name and have /crate/oldname redirect to /crate/newname with a notice at the top or something...

[carols10cents]

Aha, here's npm's current policy: http://blog.npmjs.org/post/141905368000/changes-to-npms-unpublish-policy

[steveklabnik]

Rename... I could see a case for leaving the old crate where it is for install purposes, but allowing someone to change the name and have /crate/oldname redirect to /crate/newname with a notice at the top or something...

I'd be in favor of treating rename as a specifc kind of yank, that is, the old one would stay, but you couldn't depend on it; you'd get the new one.

[alexcrichton]

@carols10cents in general yeah it'd cause breakage (e.g. to delete libc), but deleting a crate with 0 downloads and one user is unlikely to break anyone when the one user asks for it :)

[C4K3]

An alternative solution to this problem: Allow owners of crates to set them to hidden, so they by default don't show up on searches on crates.io, and have a "Show hidden crates" checkbox or something when searching.

This would maintain the crates never get deleted policy, while significantly reducing the annoyance from unmaintained crates.

[gilescope]

Can we reform the problem, everyone updates crates a lot, far more than creates new crates. Can we just introduce a special flag —yes-its-a-new-crate ? Then most of these crates would not get created in the first place. Obviously the error would say this crate doesn’t yet exist but if you want to create it just add this flag.

[fweimer]

I submitted a pull request to document existing practice regarding removals: #1506

[ndrewxie]

@alexcrichton Could you please yank every single crate/library/application under my name? Thanks. (Sounds like a ridiculous request, but there only are 2 crates under my name, which are related to each other. I wrote both of those crates in my first month of Rust, so they're obviously very nooby. Also I published to crates.io before they even worked properly lmao) It would be great if you could "delist" crates, or even delete them (but there might be dependencies that aren't on crates.io)

[jonhoo]

This is somewhat related to the ongoing discussion in rust-lang/rfcs#2614. Figured it'd be useful to have them be cross-linked.

[carols10cents]

@ndrewxie You should be able to yank the crate versions yourself; please email [email protected] if you have any problems!

[jonhoo]

@carols10cents I think what @ndrewxie wants is to entirely disown the crate such that other can (potentially) take over the time. Yanking all the published versions doesn't (as far as I know) delete the crate in question.

[ndrewxie]

@carols10cents How do you yank crate versions (my understanding is that you remove that version)? I don't see any option to do that on crates.io

EDIT: Oh wait, nevermind, cargo yank is what I was looking for.

[DevQps]

@carols10cents @alexcrichton I also own a namespace that is currently not being used anymore. I do agree that allowing the deletion of versions or entire namespaces might result in broken crates that depend on them (either crates being published on crates.io or local projects). Maybe it is nice to include some kind of deprecation period? For example that a warning is generated when cargo attempts to download such a package, and to release a certain namespace after x months?

I guess there should be some kind of balance between existing crates not breaking and many namespaces with code that is not to be used anymore.

[fweimer]

I was told that crates are never removed except for legal reason.
It feels strange that the only way to give up a name is to publish offensive material under it, triggering a Code of Conduct violation and eventual removal.

[DevQps]

I understand why they do that because you don't want to end up with broken crates. Displaying a warning and deprecation period as I proposed before doesn't solve this problem on a second thought.

However I was thinking about this:

If an author that wishes to have its namespace removed it should first yank all public versions of the crate. If the crate then hasn't been downloaded for X months, it can "safely" be removed.

It's not 100% safe but I think it is safe in 99.9% of all cases. I think retrieving back these namespaces is worth this risk (but that is my personal opinion of course)

What do you think about this @alexcrichton @carols10cents ?

[photex]

I've renamed a crate to use '_' instead of '-' and am now unable to publish. :(

[carols10cents]

I'm going to close this as a duplicate of #728.