[Pre-RFC] DNS domains as package namespaces

yaksher:

Finally, I want to remark that I think you're trying to solve 3 loosely related problems:

To clarify, I'm trying to solve the second one (multiple packages with the same crate name but different package names). The other two use cases (grouping by umbrella project, brand reputation) just sorta come along for the ride as a result of the imposed requirements.

I would personally be fine with the option to publish a crate with an opaque UUID namespace, since that solves the problem I care about, but that wouldn't be accepted, hence the use of domains to support the other two use cases too.

(note that in this case, I would argue xml@example.com is actually more "natural" than example.com/xml ; rather than breaking lexicographical search it is exactly placing the relevant part—that it is an xml crate—first and the irrelevant disambiguation that it happens to come from somebody called example.com second.

I'm not sure I follow, sorry, though that might be because I'm used to the left-to-right order used by other package managers, Rust mod hierarchy, XML namespaces, and so on. Every sort of scoping/namespacing system I know of is big-endian.

If you were looking at a group of dependencies, wouldn't you normally want them ordered as (namespace, name) instead of (name, namespace)?

I think the first case is more accurately referred to by the term "namespace"—a namespace is a name prefix which is fundamentally part of the name and just comes with a canonical way to split it into a prefix and an abbreviation for cases where there are multiple things with the same prefix.

Is it the term that's causing confusion? This may be a dumb question to ask, but if it was called a "scope" would that be clearer as to the intent?

• one is for deconflicting the global namespace by adding some arbitrary extension to a crate you wish could just be called xml, where the "namespace" is semantically less significant (and so should be lexicographically second), and

To clarify, the crate would be named just xml. It's the package name that would be longer.

A good crate (library/binary) name is short and descriptive. A good package name is globally unique and unambiguous. The current coupling of those two into a single identifier within crates.io is unfortunate, because the goals are at cross-purposes.

I want to make crates names a subdivision of package names, have crate names be short and descriptive (but non-unique), and have package names be unique and unambiguous (but long).