Recently with the new policy, the crates.io has removed lots of empty crates from crates.io, which definitely is useful and has made the overall crates.io name squatting issue less severe. I think maybe it's time for planning for the future.
I'd suggest an edition-based strategy for reclaiming names.
TL;DR Make it an official policy that stakeholders (including the Rust Project) can apply-approve-announce for specific package name reclaiming in the future edition, where these name become reserved, and these existing packages got renamed to a owner-package new name in the new edition. The old name is still accessible only from the old edition code, and emitting a warning with most cargo operations.
Overall Rules:
Companies and organizations can apply for their trademarks, products, etc.
The Rust Project can also apply for neutral technical terms.
Example:
There's a yanked package called amazon by planet-m on crates.io. If amazon applies for such reclaiming, the yanked packages will become planet-m-amazon in edition 2027 and later, and amazon name become reserved.
There's a package called request by ghmlee on crates.io. If the Rust Project applies for such reclaiming, the package will become ghmlee-request in edition 2027 and later, if there's any old existing code refering to the request package, they will work normally.
Would the original owner still be able to publish under the old name for people on old editions?
Would the new owner have full access to the version range or not be able to stomp on existing versions?
One of way of modeling this is that the edition is a version epoch that is auto-selected through the package.edition field. There is a certain degree of elegance to that.
Cargo feature migrations by Ericson2314 · Pull Request #3146 · rust-lang/rfcs · GitHub proposed that the meaning of a dependency's features value would be dependent on the version. Its a clever way of solving a big problem with feature evolution (what happens if you want to take existing default-features = false functionality and put it behind a feature?) but it means that changing a version requirement to a compatible version can break your builds. Avoiding this would require careful documentation reads or an upgrade assist tool. Even if we felt those options are acceptable for a new design, we aren't working with a new design and this would be disruptive to how people think about version requirements and would be a major shift in mindsets for the entire ecosystem.
While this proposal is different in that editions are expected to require changes and we offer a migration tool. this has a similar shift in mindset that I worry may be too significant.
On the implementation side, this would involve a major revision to the Index, including
Allowing a name to map to multiple Summarys (depending on the edition), a version epoch model would help with this
Allowing multiple names for one Summary (so we can unify the package).
A Summarys dependencies to map to the right meaning (Summarys are edition-less atm), a version epoch model would help with this
We also have edition-less interfaces that would need to work with this
Cargo.lock
--package <spec>
cargo check --message-format json / cargo metadata output a <spec>
workspace.dependencies
This would also require figuring out how to handle the symbol mangling so that amazon and planet-m-amazon are mangled the same. Normally, a rename is a breaking change.
Given that it is the same crate, cargo would compile it once with a single --crate-name value. And as such it will mangle symbols the same as itself. Dependency renaming with foo = { package = "bar" } doesn't affect symbol mangling either.
I don't think "reclaiming" should be tied to editions. We just need a way to restrict new owners from publishing releases which are semver-compatible with releases published by old owners. Additionally, it may be worth to have an open registry of such involuntarily ownership transfers, cargo update and third-party tooling then will be able to notify users about such events.
Couldn't agree more. What problem does this solve? I think "reclaiming names" is just a bad idea all around. So someone beat you to the name? So what. As long as they aren't doing something malicious it's not a problem.
Legal takeover requests. For example, a database driver under "obvious" name may be taken over by this database developer. As a user of the driver, I may prefer to get notified about this event without new owners being able to release silent (i.e. semver-compatible) updates.
Unmaintained crates. There is a lot of crates which use an "obvious" name, but no longer maintained by its owners for various reasons. You may say "just fork it under a 'smart' name", but it becomes a discoverability and coordination issue. Most users will first try the "obvious" name and if it does the job fine enough they will continue using it, despite it being potentially suboptimal, unidiomatic, or containing long standing bugs. Third-party tools like cargo audit could alleviate this issue a bit, but from the long-term ecosystem health perspective I think it's worth to have a way to "revive" such crates.
The current policy states:
If the current owner is not reachable or has not published any contact information the crates.io team may reach out to help mediate the process of the ownership transfer.
IIUC the use of word "mediate" means that if the original owner is completely unreachable, then the transfer can not happen.
If you want to take over a package, we recommend you try and contact the current owner directly. If the current owner agrees, they can add you as an owner of the crate, and you can then remove them, if necessary. For security reasons, the crates.io team will not transfer ownership of existing crates without the explicit approval of the current owner.
Yeah, the new wording makes it even more explicit. As for "security reasons", this is why I wrote that we need a way to block semver-compatible releases by new owners and notify downstream users about ownership change. It may be even useful for voluntarily transfers.