Does the Cargo team accept RFC: Packages as (optional) namespaces #3243

[epage]

rust-lang/rfcs#3243 has enough impact on cargo (and we want to make sure all voices are heard) that we wanted to have an FCP for this, rather than an informal yay/nay.

To avoid the "two team FCP" problem (both teams - 2 people must approve), we're holding the FCP here so its only "cargo team - 2 people"

Note: This issue exists purely for process purposes and feedback should be given on rust-lang/rfcs#3243

[epage]

@rfcbot fcp merge

Main effects on cargo

• Support :: in the middle of a package name, once
  • Including dep: feature syntax
• Ramifications for implicit feature names (do we support it for those?)
  • Decide during implementation/stabilization?
• What should the lib name be?
  • Decide during implementation/stabilization?
• Should we support renaming a package into a namespace?
  • Decide during implementation/stabilization?
• What should the generated .crate file names be?
• What should be used for :: in the index file paths?

This is assuming that namespace participation is only enforced within a registry when a package is published to it.

[rfcbot]

Team member @epage has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Eh2406
• @Muscraft
• @arlosi
• @ehuss
• @epage
• @joshtriplett
• @weihanglo

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[weihanglo]

What should the lib name be?

The current iteration of rust-lang/rfcs@482fae8 choose pkg as the autogenerated lib.name for namespace::pkg. This might introduce more name conflicts on build artifacts (see #6313). For example, a workspace contains both png::codec and avif::codec and want to build them into dylib.

This is not a blocker if postponing it to implementation stage is permitted, but it would be great if we can have a consensus on it.

[ehuss]

@weihanglo Can you clarify what kind of conflict you see? For rlibs, the filename should have a distinct hash between them.

The conflicts I can think of are:

• dylib/cdylib — these don't have hashes. This seems unlikely in practice, though something to consider.
• rustdoc — I'm going to leave a comment about this on the RFC.

[weihanglo]

Yes thanks, Eric. dylib/cdylib are things I am aware of. Might not be common, and if cargo can apply rename feature to namespaced package, everything would be okay. rustdoc's issue is more prominent.

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[decathorpe]

This has the potential to create massive headaches for Linux distributions which package Rust crates (namely Fedora Linux and Debian, and possibly other, less popular distributions).

For example, the mapping between crate names and package names is currently unique in Fedora (crate $CRATE is packaged as rust-$CRATE), which works perfectly, since crates.io is a flat namespace. With this addition, this mapping will break - the colon (from the proposed namespace separator ::) is not a valid character in RPM package names, and I'm pretty sure it's not a valid character in DEB either. There are only a limited number of valid punctuation characters that are usable in package names that are not already clashing with valid characters from crate names - only . and + currently come to mind ... so it will make implementing support for this feature possibly quite tricky for us.

A little more of a heads-up would have been nice ... 🙇🏻‍♂️

[weihanglo]

Thanks for the feedback, @decathorpe. It doesn't sound good from what you've said 😞. I wonder how distro package maintainer handle namespaced packages for NPM. But don't answer me here. This PR is primarily for collecting feedback from members of the Cargo team. For wider audience, you can find a general discussion in rust-lang/rfcs#3243, and perhaps post a comment there. I do think this issue worthy a look from more people.

[epage]

This comment would likely be better on the RFC rather than on the cargo-specific FCP issue.

Also, this isn't new. The RFC has also been around for years. Its been over a year in its current state.