Namespaces ensure availability by prefix. For example typescript definition packages are published under @types/ on npm. If npm only allowed like types-, if you want to declare types for a package called array but there already exists a package called types-array, you're in trouble.
There still exist problems, e.g. @foo/bar and foo-bar have the same typescript name @types/foo-bar, but that's a much rarer case compared to the former one.
1 Like
That's not quite the problem. The problem in the proposed reserved prefix system versus the npm approach is org-names-as-crate-prefixes and existing crates share a common namespace.
If someone can claim the types-* prefix in this proposed scheme (at least the way I proposed it), they do get the equivalent of @types on npm.
However, there's still an equivalent problem with the npm approach: you want to use the @types namespace for a project, but someone else has already registered the @types namespace! In either case, you have to pick a different name.
Yes, it's somewhat annoying that prefixes may conflict with existing packages whereas new org names give you a free-for-all land grab (initially, until all the good org names are reserved too), but the reason for this proposed approach is to avoid adding an entirely new layer of indirection to the Rust module system and all associated tooling like Cargo and instead do something simple and "low touch" which can be implemented entirely on the side of the registry with no changes to Cargo or Rust itself.
There is an important distinction between knowing whether a crate is a member of a particular organization's published crates and a crate name that may or may not have an organization prefix and the only way I know is to check each individual crate.
1 Like
rust-lang/rfcs PR: https://github.com/rust-lang/rfcs/pull/2978
1 Like
The way this is worded seems to be saying that we on the crates.io team have just decided capriciously to be against namespaces. I want to clarify that is not the case for me personally and I doubt it's the case for anyone on the team.
I'm not willing to accept a proposal for namespaces unless it convinces me that the benefits of adding the namespaces in the manner of any particular proposal outweighs the costs of its downsides in user experience and added complexity in implementation and maintenance, in both my opinion and in the opinion of different kinds of users in the community. I have not yet been convinced.
22 Likes
You are correct that I don't see any crates.io team members on the thread you linked to. Perhaps this is unclear in our RFC process, and as our RFC process continues to evolve, I will make sure this gets documented: the teams aren't obligated to monitor or respond to pre-RFCs posted on internals. The purpose of posting a pre-RFC to internals is to get feedback from anyone in the community. After you've refined your RFC through that feedback and you post an RFC on the RFCs repo, then the team will add it to their queue.
8 Likes
By the way, I left a comment on that RFC on what my personal requirements would be for a namespaces RFC, and a possible direction that satisfies most of them 
7 Likes
I glanced at the previous posts and linked threads ā well, it's a significant number of posts, so forgive me if I repeat or miss something.
I generally like the idea of having some crate namespaces that could group related crates. It is useful for easier discovery of related crates and when a crate belongs to a group, which I already know and trust, I know I can expect some standards etc. Quite often concern, related to the trust, was about acquiring the group identifiers and binding them to domain names or so. Maven was mentioned several times as both good and bad example. An interesting post mentioned the problem of gatekeepers. I'll try to share some thoughts that might perhaps be inspiring.
I think it is a good thing to have the possibility of independent registries. It allows for alternative sources to be created because of various reasons, for instance as a caching mirror of crates.io. However, there is no reason why registries could not have different policies, for example, someone might maintain a registry with redacted content and hosting high-quality proven crates only. IMO, the possibility of independent registries might solve the gatekeeper problem.
Maven for comparison works like that. Although there is the Maven Central repository, used as the default, it is possible to configure other repositories that Maven should use and ā here it becomes interesting ā even filter which (artifact) groups should or should not be provided by individual repositories. This can be used, for example, in companies with their own Maven repository to mirror and trust only some sources. Btw. Apache or Eclipse Foundation have their own Maven repositories, where even snapshot builds are available, and releases only are mirrored to Maven Central.
Assigning group identifiers depends on the registry's policy. This leverages the freedom provided by independent registriesā¦ and the freedom to choose. One could argue that it means that the group/crate does not have to be unique, because it depends on the particular registry. This is trueā¦ and it means: use reasonable registries to work with.
As noted above, Maven provides such a freedom (there is nothing stopping anyone to take an artifact and re-publish it to a different repository), but I guess there is no problem. Most people are happy with Maven Centralā¦ well, the cost for the trust is paid by the registration process and requiring the group to be the domain name belonging to the account owner.
I guess this point therefore leads to the question how to set the policy for crates.io? Following answers are likely flawed, but anyway here they are to kick off the discussion:
- First come, first served might not be as bad. How are taken the account names on GitHub anyway?
- Existing account names could be used as the pre-reserved group identifiers.
- Suitable group identifiers could be offered to existing accounts for their projects (I guess that the offered identifiers might be proposed automatically based on the project names.)
How to handle crates published so far without any group? Maybe the registry could have a default public group and all existing crates would automatically belong to this public group. Referring to a crate without a group then defaults naturally to the registry's default group.
Groups serve for grouping and don't have to be linked to crate names. By this I mean that for a group like serde, the crate would still be named serde/serde_json and thus nothing changes for the compiler. I guess this point might raise the question whether the groups are really good for anything. But yes: there is the relationship to maintainers, filtering if multiple repositories shall be used and a group may create a crate without concerns whether the name was already taken or not.
If I use Maven again as an analogy, the group identifier never appears in the source. Just by convention, the namespaces in the artifact usually begin with the group identifier and sometimes (especially in the OSGi world) artifact identifiers include the group identifier too.
What happens if I meet foo/random and bar/random? Not much: in such a case I'm forced to rename random to something else. But how often such a name clash occurs? I guess the clash occurs more often with such generic names on the side of the crate's authors. Even with group identifiers it remains good to offer a distinctive name, but the pressure is not so high, especially when the nature of the crate makes less probable to use it in conjunction with a possibly same-named crate. It opens the opportunity for someone to implement my/serde_bson and after a great success to offer it to serde to adopt as serde/serde_bsonā¦ not much changes for the crate consumers.
Last to mention might be the check list:
The proposal should be backwards compatible with the current situation.
Defaults should do the trick: the default registry crates.io with the default public group. Users must explicitly tell otherwise.
The namespaces should be stable and immutable like the rest of the registry, and it should not be possible to rename them. Once a namespace is created it should not be removed.
This I would leave to the registry's policy. But that's IMO no problem, of course, crates.io would never remove a group.
Implementing namespaces shouldn't hurt the usability and ergonomics of crates.io, for example by having random or identifiers users aren't expected to remember.
Although I used in examples the syntax group/crate, which I personally like, this point remains flexibly open 
Namespaces should not restrict others' ability to publish packages without the namespace (for example, by allowing people to reserve a foo-* prefix).
If the registry's policy allows a default groupā¦ no problem. But using explicit group (even the default for the given registry) should be probably encouraged and preferred to the default.
Namespaced crates should be usable inside the source code without any renaming, and that should not create collisions.
Almost, see the notes above.
Well, that's all I have. Good night.
1 Like
Don't have the time right now to properly respond, but to be clear that's my personal checklist: I'm on the crates.io team, but I have not consulted with any other team member. That's just what I'd need to see in a proposal for me to approve it.
I respect that no one is (or should be) required to spend their personal free time reviewing and participating in various discussions. Volunteers working on OSS are already underappreciated. That said, I think drafting a whole RFC with zero input from the team that owns the project/component in question is a recipe for failure and frustration.
Is there any guidance on how people can interact with project owners? In this situation it's the crates.io team but I think this same question applies to any of the teams. If IRLO isn't the right forum, what is?
People are trying to engage with the right teams but we need guidance on how to do that, especially if IRLO isn't the right place. I know this could easily lead to teams being swamped and overwhelmed with people trying to engage them. I'm not sure how to solve that, but I hope that whatever solutions are implemented are publicly documented and clearly accessible.
3 Likes
It appears that soc's skepticism regarding crates.io being open to the idea of namespaces in general was well founded. Per conversation on the RFC, and strong pushback from the crates.io team on allowing multiple packages to contain crates with the same name, I have closed the PR.
Various Rust team members have expressed that getting an RFC accepted is a lot of work as well. There is work being done to improve the entire RFC process, but that is hard work and takes time too.
Complex RFCs have even had multiple people working on them and managing them-- perhaps folks who want to see namespaces introduced to crates.io the most could work together on an RFC.
Stability is a philosophy that we apply not only to the language, but also to the tools and ecosystem. Any large changes to the way Rust works go through careful design and consideration before they're accepted, and we will take the same care adding namespaces to crates.io.
9 Likes
- a. I am not on the crates.io team.
- b. I know this is somewhat flippant.
The priorities of the team are decided by the team. If convincing the existing members of the team that you have it figured out isn't working then do the work to get on the team. Getting on the team is not hard. Find out what the current priorities are, by looking at issues or by reading the team meetings that are public on discord. Then help with those problems for a while. When you have demonstrated that you are a helpful voice you will have more influence on the thoughts of the team. You may even be asked to join. (I don't know how formal the inclusion process is with the crates.io team.) I suspect someone on the team that is willing to say "this is enough of a priority for me that I would do the implementation" may be helpful to getting a complex RFC supported. Reminder I am not on the crates.io team, but I know it is relevant in the team I am on.
1 Like
Usually when one of these namespacing pre-RFCs is posted, someone helpfully posts a summary of previous relevant work in that area. I guess that didn't happen in this issue.
Here is a list from ~1 year ago on a namesquatting-related thread, but it also includes several pre-RFCs on namespacing as namespacing is often suggested as a solution for namesquatting:
2 Likes
Are there any communities where a large disruptive change like repository name spacing could ever be driven by āoutsidersā to a project? IMO the priority should be on shortening the path to being an āinsiderā rather than making it easy for anybody to influence the community regardless of their stake.
I think framing proposal strategies in terms of mutual respect is excellent. What would that respect for the crates.io team look like in this case?
I agree with this need but I would frame it differently - from what I can tell many teams need guidance, practice, and support in incubating proposals that cross longer time spans. Itās a problem for the projectās ability to scale all over, not just for this one set of features for crates.io.
Organizing is a hard problem! I think there are probably more constructive ways to approach this than āwhich venue is appropriate for us to put design proposalsā - the question could instead be āhow can i find out about the open questions for a particular problemā (although on that point I agree the project is playing catch-up).
6 Likes
I think you're reading into this too much, and likewise, when you propose a large change to a running complex system, you need to be respectful that it will both have a high bar for acceptance and require you invest a lot of time.
From the perspective of an outsider with my own ideas about how this particular feature should be implemented, honestly I think the main problem with all of these proposals is they routinely do not take the relatively clear feedback about what proposals will be considered into consideration when authoring them, and tend to either introduce backwards incompatibilities or things which would require cross-cutting changes across multiple parts of Rust.
This is why I have steered towards solutions which require changes only on the crates.io side alone. I haven't put the work into making a concrete proposal because I do consider the time involved to actually see it through, and feel there are other places I could better invest my time. But that's a personal decision on my part.
19 Likes
If I had been told that one or more members of the crates.io team objected to the idea of namespaces in principle, then I could have short-circuited this wasteful exercise.
This seems to be refuted in the next comment. Unless I've missed something, I don't think this quote fairly represents the discussion in that thread.
Whatever you think of this feature, it is very clearly not a bug fix. This is only one example of a large pattern of language from users who care about introducing this feature to diminish the difficulties it presents and raise the stakes for adding it. It is very frustrating to communicate with people who present themselves this way. Adopting this sort of posture will not be successful in introducing change to any part of Rust.
21 Likes