[TheCycoONE]

Conversely the arguments I've heard for namespaces is that multiple people want to reimplement or make bindings for the same C library.

In maven central, in my anecdotal experience, namespaces usually either distinguish forks of the same library, or to group related libraries. There has never been, in my experience, a case where I wanted two packages with the same name in different namespaces.

I think a better system of handling unmaintained crates; with the possibility of reclaiming a name would go a long way with the author's use case. I don't have any great ideas here: package with no update in some time (a year?) is eligible. Someone requests to take over name - the author is notified and has a period of time to click an "I'm still here" button. If they don't - new author gets the name. Some 'super version' number is incremented so crate authors opt into the new or old foo. That last part is where I'm the most hesitant.

[stefan_]

Of course a single project is very unlikely to depend on two different packages with the same name. But a global repository of all packages is conversely extremely likely to have many many people all wanting one name - it's essentially a .com registry.

Reusing project names is just a straight no-go when that is what other peoples projects depend on. As soon as a package has a dependency, (name, version, source) need to be absolutely immutable.

[boris]

As the person you are replying to suggestes, a version epoch could be a solution.

[mlindner]

There's a bigger problem that someone has reserved a ton of common names and they're all empty projects with nothing in them.

[viraptor]

Or even in a non-malicious case: https://crates.io/crates/logger

"logger" is now forever a middleware for the iron framework. Same with "router". Iron is pretty much obsolete now.

[rat87]

that sounds like a good thing.

It might have been good if the rust team themseleves had pre-squated

get rid of all the common names arguments and have everyone use prefixed or unique names