Thoughts on Allowing Crates with the Same Name

tools and infrastructure cargo
1

Current Issues

The lack of namespaces for crates currently leads to several problems:

  • Crate names being "squatted" or reserved unnecessarily.
  • Popular crates being maintained by non-official parties, causing potential confusion.

Challenges with Introducing Namespaces

Introducing namespaces also brings its own set of challenges:

  • Users may dislike having to include the owner's name in configuration files.
  • Namespaces might not always indicate official ownership.

A New Proposal: Allowing Crates with the Same Name to Coexist

Here's an alternative idea: allow multiple crates with the same name to coexist.

Implementation

Each crate would be assigned a unique ID. The ID could increment sequentially for each new crate with the same name. The first crate published under a specific name would always have an ID of 0 for backward compatibility.

  • When the crate name is unique on crates.io, the behavior remains the same as the current setup. If the ID is omitted, it defaults to 0.
foo = "1.0.0"
  • When multiple crates share the same name, cargo add would fail without specifying the ID. In this case, users would need to provide the crate's ID explicitly, like this:
foo = { version = "1.0.0", id = "1" }
  • In extreme scenarios, where users need to use multiple crates with the same name simultaneously, this isn't an issue. Cargo already supports aliases for crates in Cargo.toml.

Example with Aliases

foo1 = { package = "foo", version = "1.0.0", id = "0" }
foo2 = { package = "foo", version = "1.0.0", id = "1" }

Apologies for the previous absurd and immature suggestion. I now propose an alternative approach that appears more intuitive (though equally impractical to implement) - a solution I believe most people would naturally consider:

foo = { version = "1.0.0", namespace = "bar" }

This approach suggests:

  1. Non-unique crate names on crates.io, while enforcing unique namespaces
  2. Implementing a namespace verification system on crates.io to indicate official ownership
  3. Potential future integration with IDE tools like VSCode to display verification badges in TOML plugins

Introducing namespaces at the Cargo.toml configuration level seems less intrusive than implementing them in code. While namespace squatting remains possible, this system would:

  • Eliminate the need for developers to invent unique crate names
  • Provide clearer ownership indicators
  • Maintain backward compatibility

The trade-off between namespace contention and naming freedom might be more acceptable than the current naming collision challenges.

1 Like
2

I think this will only cause confusion.

10 Likes
3

I think the best we could do (this has also been discussed before, I just couldn't find the thread), is to have a field in the manifest that would allow you to specify which other packages yours is similar to. Then, when installing either package, a note would show up listing some similar packages.

This, in and of itself, could be used by spammer crates to inject their crate into the similar list of popular crates. The way I'd mitigate that is to have the list sorted by a "trust metric" (computed from popularity, maintaining account, etc.) and only crates with a good enough trust metric show up in the similar list at all.

4

Strictly speaking, this is already true. The manifest package.name and lib.name are independent identifiers, and deriving lib.name from package.name is only default convention.

For example, to pick on my own crate, a dependency of build-rs = { version = "0.1" } is functionally the same as build = { package = "build-rs", version = "0.1" } because I set lib.name in the package manifest manually.

3 Likes
5

I am tempted to suggest that, rather than having the disambiguator be a sequence number assigned by crates.io, it should be a VCS repository URL for the package you mean (like the existing support for git = <URL> in dependencies) and a full commit hash which is an ancestor of the version tag you asked for. Something like

[dependencies.mastodon]
# we need features specifically from the hometown fork
version = x.y.z
origin = {
    url = "git+https://github.com/hometown-fork/hometown",
    commit = "..." # an early commit in the fork
}

This would not pull the actual code from the repo URL, it would just use the URL and the commit as identifiers for which package called "mastodon" you mean.

(fake scenario for expository purposes only, mentioned software is real but not actually written in Rust)

1 Like