Tracking Issue for Packages as (optional) namespaces

[epage]

RFC: #3243

• rustc tracking issue: Tracking Issue for Packages as (optional) namespaces rust#122349
• cargo tracking issue: Tracking Issue for Packages as (optional) namespaces cargo#13576

Allow a parent package to open its API namespace for other packages to participate

Implementation:

• Allow one :: in the middle of package names

[epage]

Some ideas on the UX

• Make the parent in parent::child a link to the parent package
• Have the parent package list all parent::child packages

One UX problem I can think of for listing all child packages is not all are created equal. liquid is a good example of where I can use this feature but I have liquid-<child> packages that are deprecated. In this scenario, they will all be shown equally. In rust-lang/cargo#2608 I bring up the idea of a user and Project editable database. We could collapse or outright hide deprecated packages if we had a way to track that.

See also

• Move "Maintenance Status" into the crates.io UI #2437
• Changing metadata should be possible without bumping a version #7146
• Look into ways to decouple some crate metadata from Cargo.toml #3167

[jsha]

FWIW, what we do in rustdoc is to be explicit: if an item is deprecated, we don't try to hide it. We include it, and mark it deprecated. I think this is also the right choice for cargo. People will find the names of deprecated packages in outdated documentation, recorded talks and so on. So the quickest way for them to learn the most up-to-date information is to see those packages listed and marked as deprecated.

If it turns out there are namespaces that have so many deprecated packages that it becomes hard to find the non-deprecated ones, it could make sense to have two sections: "Packages in this namespace" and "Deprecated packages in this namespace."

[epage]

How precisely should this be represented in the index trie?
How we should name the .crate file / download URL

Looking through the RFC for all relevant comments on these

• RFC: Packages as (optional) namespaces rfcs#3243 (comment)
• RFC: Packages as (optional) namespaces rfcs#3243 (comment)
• RFC: Packages as (optional) namespaces rfcs#3243 (comment)
• Decision: Separator choice Manishearth/namespacing-rfc#1 (comment)

General requirements is that the index trie and .crate names need to be cross-platform

• : is disallowed on Windows
• alphanumeric, .+- are generally the characters supported by distributions wrapping .crate files
  • for go (mapping URL to distribution package), they replace reserved characters with - but migrating from packages using - to :: could cause conflicts
  • for php (with /), map to -
  • for perl (with ::), map to -

imo what cargo should use should be unambigious. This means we shouldn't map to -. To support distributions, that leaves +. Thats fairly restrictive if we ever want to support anything else, like registry namespacing (and not just API namespacing). I somewhat lean towards percent encoding of package names.

[drmason13]

Would it be possible to use -- instead of just - to replace ::?

Even if -- (or __) is allowed in crate names today, it's at least uncommon.

[epage]

@drmason13 my proposal was to not use - and I'm not seeing any counter proposals here. We might choose to use that internally in Cargo but that is relevant for the cargo tracking issue.