4 ms·

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

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.

mlindner 6y ago
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 6y ago
  Or even in a non-malicious case: https://crates.io/crates/logger 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 6y ago
  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
stefan_ 6y ago
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 6y ago
  As the person you are replying to suggestes, a version epoch could be a solution.

mlindner 6y ago

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 6y ago
Or even in a non-malicious case: https://crates.io/crates/logger 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 6y ago
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

stefan_ 6y ago

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 6y ago
As the person you are replying to suggestes, a version epoch could be a solution.