This Pre-RFC summarizes and is inspired by existing discussions on crates-io crate namespaces. It extends existing ideas to allows crate owners to attach author identifiers prior to project names, to avoid name collision with existing crates. The new naming system may coexist with the present one for backward compatibility. The document also declares how crates should be quoted as dependencies in cargo-toml configurations.
RFC expects to solve possible software security issues and name rush-register problems, and expects to help developers choose high quality crates.
This is such well trodden territory that i was able to make a long list of other related posts the last time I saw it
See:
Any new proposals should say why this solves problems that previous proposals didn't (note: I didn't read the RFC, so this may have been done this time)
If it's not a huge problem on domains level (not huge enough to change something), it's not enough big problem for creating issues on crates.io level.
Every "Pre RFC" about crates names brings proposals to create some additional requirements, some issues, some fences and obstacles. Most sensitive to them are new Rust users, so I always vote against any fences in this field. Rust have enough issues for newbies.
I think it's something I really want to have. The name conflict I think should be finally a serious problem. Once instance for this is:
The crate jemalloc is a low quality wrapper for jemalloc, undocumented and not maintained.
And the first time I want to use jemalloc allocator, I just add that crate and not working. But the correct crate should be import is jemallocator which isn't a good name for it in my opinion.
In long term, I believe this would finally become a problem if there's nothing to prevent people occupying meaningful name meaninglessly.
There are a lot of well-known term which is squatted by meaningless crate already, I don't think the long term solution should be leave them there forever.
I do really think it's better to make all crate have user::crate namespace and some community adopted crate can have a top-level alias. And the top-level alias is maintained and reviewed by the crates.io team. (And I believe this is what Docker Hub is doing)
Another benefit would be people can have their own fork of some existing crate published under their own name. But currently it's very hard to have that.
But the problem is this will fundamentally break to most of existing code and introducing extra maintenance burden.
What I am saying is not suggesting any change, but I think there would be some issue in the future if the community keep growth.
Searching is one thing, but naming is another problem. Although people can find what they need by having well maintained crate index. However, the name loss its self-documenting function is really a bad thing.
If jemalloc is the exact crate to use jemalloc, I can just add it to manifest file without any crate hunting step. The concern isn't people can't find it, but people have to use bad name for their high quality crate. I am quite sure people who see jemallocator can easily guess what it's used for, but I mean this is an additional burden to developer, ideally this should be avoid.
Personally, I like the idea of user/name crates by default and a curated top level for recognizable and widely adopted libraries (that either are a canonical implementation with the generic name and some promise of continuing support, or a "brand name" for noncanonical crates). The code level actually wouldn't see a difference, just the metadata.
However, this just won't work for crates-io. Why? Because of legacy crates and forwards/backwards compatibility. The current crates would need to keep their top level name, and would gain an unfair position given their "curated" position without actual curation.
Plus, it adds a whole new "attack surface" and community cost to the actual curation of top-level names.
For the immutable registry that crates-io, the first-come-first-served naming policy is actually a very decent local maximum. Unfortunately, we might be stuck with its drawbacks because the effort involved in finding another local maximum and transitioning to it is more than the crates team can afford at the moment.
I thought about this, there might be a workaround for this actually.
We can actually introduce a new configuration in the Cargo.toml which defines the "default user".
Let's say cargo will find the crate under "default user" before actually find under the root. And we can have a virtual user which is mirror of the entire site. And by default the default user is set to the virtual user, thus any existing code still compiles with the new system.
However, the newly added code can gradually adopt the new pattern and finally we can deprecate the virtual user.
You can use wildcard for the version for sure unless you publish it. But this requirement actually this is one reason why cargo-edit exists - You don't need to go to crates.io to check what is the latest version is.
And then other developers will have exactly 0 motivation to create something else even if they know how to do it better. We should have a competition, it's vital for quality.
I don't get the point, why motivation is related to putting their name as namespace for their own crate?
In your case, people can actually use a name different its competent and push hard to make it a global alias. Because of the higher bar for the global name, it's actually more option for the later comer to adopt a proper name. Currently a lot of name is used by squatters and I don't think this gives people any motivation to make better crates. But this do gives people motivation for squatting names for later use. (And I personally did a little bit of this, since I have my own project specify crates that I may be publish later but now I have to squat it unfortunately) And this doesn't give me any motivation to make anything better
Actually, people is motivated to make community adopted crates in this case and the Rust team have more control on if we should give the community more stimulation by adjusting the admission bar of the global alias.
Making things out of control isn't a solution that make people motivated.
Because when there is already existing "community elected" crate, it creates inequality - people will use what is "community elected" and give not enough attention to alternatives.
But this is happening anyway right? Adding author name to crate doesn't actually change this. Today you can still see a lot of dominant crates. If the Rust team lower the bar for global alias admission, there would be quite a lot crate is eligible for the global namespace.
For early stage crate even today there's a visibility issue. Plus if the global alias exist, I am quite sure high quality crate would quickly get the ticket to the root namespace and have even better visibility.
However, for today's situation, some awesome new crate is soaking in a ocean of randomly created, never maintained crates. And I think this is the number one inequality for all serious crate authors.
There could be methods to protect names, but trademark or patent protection may only apply to project author names, but not project names.
That's not how I understand trademark to work, and we don't have the power to change that.
For the idea overall, if you want to name your crates yourusername-yourpackagename, as @jmjoy suggested, there's nothing stopping you from doing that today.
Furthermore, transferring of crates from one person to another, as @proc mentioned, would need to be addressed. I see the "alias" section, which covers publishing, but how would I know one crate was an alias for another if I'm looking at crates.io?
This also doesn't take into account that today, crates.io accounts require GitHub accounts, but might support signing in with other accounts in the future.
I think the "Downsides" section contains great points, but I don't see justification for why those downsides are acceptable in relation to the downsides of leaving crates.io the way it is currently.
But in fact there is, plus if the badge's bar is as low as some crate that is seriously maintained, I don't see there any problem of that. Plus if you look at libs.rs, don't you think the top crates are actually some badges? Don't you think lib.rs create an inequality for all crates since all crates are born equal? If this is the case shouldn't any crate ranking system be banned completely? Explain to me why the home page of lib.rs is different from root namespace on crates.io
Make high quality works soak in an ocean of low quality ones are more concerned than giving high quality one a badge, isn't it ?
Why the equality should be defined as squatters and never maintained crates should have the same privilege as a serious author and a carefully maintained crate? I can't see why this is more encouraging people making contribution to the ecosystem.
In a contrary, I think if there no good rewarding system for serious authors who actually build the ecosystem, people will be demotivated very easily, isn't it the case?