Child Thread: Survey of alternative identifier designs for Cargo and Crates.io

For background context and links to other threads, see Survey of organizational ownership and registry namespace designs for Cargo and Crates.io. This thread assumes that one has been read.

This thread is for summarizing approaches for avoiding squatting by changing how we identify packages. Other general approaches include:

• Child Thread: Survey of alternative identifier designs for Cargo and Crates.io
• Child Thread: Survey of registry namespace designs for Cargo and Crates.io

Debating which proposal Cargo andCrates.io should go with is off-topic for this thread. Please create your own thread.

Prior art

Those relevant for this thread

Julia Pkg UUID

Each package has a name, version, and UUID.

The dependency name is the Julia namespace used for the package. Project.toml maps the dependency name to the UUID which is then used to identify the package.

As a parallel to cargo add, you can add dependencies with the REPL. Users can pass the package name to the add command.

TODO:

• If names are used on the command-line, how are they resolved?
• Presumably, packages can be renamed, so how do they deal with pkg> add foo changing meaning over time?

Motivations:

• Changing names without breaking people
• A shared, flat namespace between local packages and registries when resolving dependencies

References:

• PackagingCon: Julia's Pkg – Design & Rationale (2021)

Potential solutions

Unreserved prefixes (no-op)

Maintainers could name their package <namespace>-<name>.

For brevity in code, maintainers can drop the namespace within Rust by setting lib.name = "name" or users can rename the package in their dependencies table.

Compared to use cases:

• No trust in the namespace as anyone can publish in it
• Not friendly to renames or namespace transfers

Compared to requirements:

• If using the lib.name trick, how to reference the package in Rust code is unclear though that is an existing issue for renames and kebab case (cargo#15887)
• Without the lib.name trick, access within Rust is verbose

Future possibilities:

• Encode this in the ecosystem by adding to .cargo/config.toml a cargo-new.prefix = <string|bool> with a default of $USER for packages not being added to workspaces
  • advice will be given for changing this
  • Users can always disable with cargo-new.prefix = false
  • Repos that want to default to their Rust namespace can set cargo-new.prefix = "namespace::"
• Resolve cargo#15887, making discovery of Rust namespace more discoverable

Package-level extern name

In effect, this is promoting lib.name to a package level property that is used in the UX for Cargo and crates.io. We are renaming this from 'Package "display name"s' as that implies this is for UX purposes only and does not have an impact on compatibility.

Users manually manage conflicts in their naming of the package but can also set a package-level extern name for what they desire should be shown. As an extern name, this is the name it is referenced by in Rust code. The main way the user interacts with the package name is in dependency declarations.

Compared to use cases:

• No trust in who published the package
• Communication of packages will be difficult
• Users will be prone to depend on the display name, not the package name, pulling in the wrong dependency

Compared to requirements:

• No correlation between the dependency and the namespace in Rust
• Import collisions are possible which impacts usability. Like with multiple semver-major versions, users can rename the package.
• Confusing having to interact with two different names

References:

• Internals: Crates.io “first-come, first-served” for plain crate names - why and how should it be changed? (2023)

UUIDs as package identifiers

Like "Package-level extern name" but deprecating package.name in favor of a unique ID.

Compared to use cases:

• No trust in who published the package
• Communication of packages will be difficult
• Users will be prone to depend on the display name, not the package name, pulling in the wrong dependency

Compared to requirements:

• UUIDs in dependencies would be meaningless to the user
• No correlation between the dependency and the namespace in Rust
• Import collisions are possible which impacts usability. Like with multiple semver-major versions, users can rename the package.

References:

• Internals reply: Crates.io “first-come, first-served” for plain crate names - why and how should it be changed? (2023)
• Internals reply: Crates.io “first-come, first-served” for plain crate names - why and how should it be changed? (2023)
• Internals reply: Crates.io “first-come, first-served” for plain crate names - why and how should it be changed? (2023)

Unique suffixes

Like Discord’s DiscordTag, usernames are assigned a server-side suffix that is used to qualify which package of that name it is.

e.g.

[dependencies]
"libc#9274" = "0.3"

It is presumed that the suffix is dropped when used in Rust code.

Users will need to pre-register their packages and update their packages to use the suffix. The RFC said that this could be done at publish time but there needs to be a way to know which suffix is intended. It can't be (package-name, publish-owner) as there can be multiple publish owners and one could have a prior version of the package or want to fork it short term.

Compared to use cases:

• No trust in who published the package
• Typo squatting becomes easier as harder-to-remember numbers are used and typo squatting monitoring doesn't help as easily-typoed names is an intended use case
• Communication of packages will be difficult
• Users will be prone to depend on the display name, not the package name, pulling in the wrong dependency

Compared to requirements:

• A package cannot be published to multiple registries as its suffix may be different
• Numeric suffixes will be difficult for users to distinguish packages
• Technically, how to reference the package in Rust code is not 1:1 with the package name but dropping the suffix is likely an easy thing to pick up along the same lines as switching kebab-case to snake_case (cargo#15887)
• Import collisions are possible which impacts usability. Like with multiple semver-major versions, users can rename the package.

References:

• Internals: Pre-RFC: unique crate names (2019)