State of

Actually I try to find a name for a crate that does not collide with a existing crate name that is not used and maintained by the owner since 3 years.

I would like to now the state of some namespace feature in for developer/company that want to share a crate with a name that is not fancy.

Do a namespace feature is on the plate?
Something to reclaims dead crate no longer supported or used?

Thank you

I don't know about any plans in that matter. I personally miss namespaces too (and would like something domain based, so it's less centralized). An alternative is to specify a Git repository as dependency in your own crates, but this doesn't integrate with, because packages with such dependencies are rejected.

1 Like

Discussion on the Packages as (optional) namespaces RFC has stalled a bit.


Only if the owner agrees.

1 Like

What makes you think a crate is no longer supported or used? If I die, I don't want my crates to be taken down by some random guy from the internet 3 years after my death because he/she likes my crate's name too much. Note that in most countries artistic works are copyrighted during 70 years after the author’s death, and even so, you cannot claim authorship of Shakespeare's Romeo and Juliet.

Yes I did it. Waiting for the answer :slight_smile:

Indeed, the time since the last update isn't a reliable information on the quality or maintenance state of a crate. But therein lies the problem: There's no easy way to quickly figure out which crates are good to be used. Maybe aims to provide better algorithms for that (I haven't looked into it much), but ultimately something like a web of trust would be good to have, or a rating system of some kind. (Not sure if that's feasible at all; just a crazy idea for now.)

That's not a direct answer to the original question, but you can be nevertheless interested in cargo-crev.

Easy boy :wink: !
What make me think the crate is not used is the empty dependents list. Version is still 0.1.1 since 3 years. No commit since 3 years too... Developer is contacted with no answer... Well at some point, need a way to treat this type of situation with namespace or scope like NPM.

About Shakespeare's, do not own anything, the code is on GitHub. even GitHub do not own anythings... Even if deleted from, the code still exist.

It give me the same false assertion that make sure code will always compile because of this type of rules, this is false, user can still delete github code, move it to GitLab or whatever.

At least, another minimal solution that is done in other domains is to send a mail after some month of inactivity and asking "Hey, are you still alive? Your crate seems dead, hope you are not too... Click the link below to keep your crate activated, or this link to allow user to reclaim it!".

My "solution" is to ask in this forum when I'm unsure which crate to use. While I really appreciate all the help I get, I still think that some (semi-)automated system could be a good thing to have. It won't work without human input, but allowing that input to be structured better could make the ecosystem much easier to use, I think, and use the human input more efficiently (you won't have people asking over and over about a crate).

1 Like

But not all crates are libraries... In fact, none of my crates is intended to be used primarily as a library. You will definitely take all my hard work down 3 years after my death because of the empty dependents list... :sob:

Seriously, the main reason why I've chosen Rust and not some other programming language are all the promises of "stability", etc. Crates should stay there unchanged, available for download, and easily installed in perpetuity. If Rust changes its current philosophy, I'll need to switch to another programming language...

And what is GitHub gets the same idea and starts to delete "dead" repositories?

1 Like

Ouch, so crates written my people who have died or otherwise lost interest in them would effectively be deleted and their names available for use by someone else for some totally other purpose.

Sounds like a disaster. I could end up depending on a crate that suddenly disappears or morphs into something else, despite the fact the original works well.


There's no requirement for crates to have their code on GitHub (or in any kind of source control, for that matter). When you add something as a Cargo dependency, it gets downloaded from


I see no reason I could not write a book and call it "Romeo and Juliet". Of course people might be a bit miffed when they ask for "Romeo and Juliet" and get my book on rabbit breeding or whatever instead of Shakespeare's effort.

I'd say you can write a book called Romeo and Juliet, making an allusion to the original Shakespeare's work, just like you are free to fork any of my MIT-licensed crates. However, you cannot claim ownership of Shakespeare's works. There's a huge difference between forking and claiming an ownership.

Please, correct me if I'm wrong, it seems that the Rust Foundation is based in the USA, right? I'm not really familiar to the US law but this whole proposal to claim ownership of other people's crates without a very explicit agreement of the crate's original author looks like a clear violation of intellectual rights (or at least it would be a clear violation of intellectual rights where I live).

Exploring the transfer of names without the author's participation has been discussed a lot, often in the context of squatting. Here's an IRLO thread with links to prior discussions you could read. And here's an RFC trying to get any amount of traction on the concept (still open after 3.5 years).

1 Like

I wonder if this is even true. Given that Shakespeare was working long before copy right law exited and would be way out of copyright's time span anyway I see no reason why I could not copy his writing and publish them under my own name. Well, except that would make me look pretty silly.

Don't forget there is even debate over whether Shakespeare even wrote that stuff.

Also I see no reason why I cannot write a book called "Romeo and Juliet" with no allusions to Shakespeare's work at all.

True! :joy: