Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.



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.


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


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


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.


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




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: