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.

[pksunkara]

From the RFC regarding migration:

A possible path forward is to enable people to register aliases, i.e. unic-langid is an alias for unic::langid.

@epage Are there any thoughts of implementing this as part of this work or is it considered for later?

[epage]

Aliases like that seems like its a feature on its own that needs an RFC.

We've talked about a mutable metadata database that could notify people of moves (e.g. structopt to clap) which could also apply to this.

A further workaround for the transition is to bump major on the reexport with a compile_error. Haven't tried #![deprecated] within a root module to see if that can work with the reexport crate.

The main place that would "need" aliases is if there are vocab crates that would want to migrate to this.