Tracking Issue for Packages as (optional) namespaces

View all comments

This is a tracking issue for the RFC "3243" (rust-lang/rfcs#3243).

• crates.io tracking issue: rust-lang/crates.io#8292
• cargo tracking issue: rust-lang/cargo#13576
• docs.rs tracking issue: rust-lang/docs.rs#2457

About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.

Steps

• Implement the RFC (can anyone write up mentoring
  instructions?)
• Adjust documentation (see instructions on rustc-dev-guide)
• Formatting for new syntax has been added to the Style Guide (nightly-style-procedure)
• Stabilization PR (see instructions on rustc-dev-guide)

Unresolved Questions

• How exactly should the Cargo.toml lib.name key work in this world, and how does that integrate with --extern and -L and sysroots?
• Decide on and document precise name conflict rules for the compiler (https://github.com/rust-lang/rfcs/pull/3243#issuecomment-1789240624)

Third-parties, like Linux distributions, will need to decide how to encode
cargo package names in their distribution package names according to their
individual rules.
Compared to existing ecosystems with namespaces that they package, the only new
wrinkle is that there can be 0-1 namespace levels.

Implementation history

Start by reading RFC 3243 and the linked Cargo, crates.io, and docs.rs tracking issues to understand the implementation scope. The unresolved questions specifically call out Cargo.toml lib.name, --extern, -L, sysroots, and compiler name conflicts; completion requires resolving those questions and progressing the listed implementation, documentation, formatting, and stabilization steps.