Pre-RFC: Packages as Optional Namespaces

Moderator note: Thank you to most folks for contributing to this discussion productively. Comments that do nothing other than say "this is wrong and it has been pointed out to you" are vacuous and unhelpful. A goal of this discussion should be to approach a shared understanding, and simply pointing and saying "you're wrong" over and over again does not help us reach that goal. Please stop doing that.


I think a disconnect that is cropping up here is that reverse domain notation is better suited to solve the following problem:

(especially since @ehiggs suggests that for backwards compatibility existing crates become

This solves a different set of problems. It makes indicating organization ownership harder for everyone (which is the main goal of this pre-RFC), and it makes everyone have to start thinking about namespaces (an explicit non-goal of this pre-RFC).

I very deliberately defined the scope of this discussion at the top to prevent having a situation where people talk about solutions to different problems and talk past each other:

So unless someone can make reverse dns match with the stated motivations of this pre-RFC, I'd request discussions of that proposal go in a separate pre-RFC.


Reading the proposal again more closely I think the limited scope makes this orthogonal to e.g. reverse-DNS and authentication of users.The only thing being proposed here is that instead of being two levels (project, version). There would now be three levels (group, project, version) and the group is currently a string with no meaning anywhere else.

'.'? :slight_smile: It would avoid ambiguity in feature syntax, could prevent ambiguity with foo_bar and would hence mitigate typo squatting.

Drawbacks: It would also require changes in rustc and new packages wouldn't be usable in older versions of rust.

Already covered in the original post:

This is not a dealbreaker, but it's something we should recognize.

You previously said the default group for everyone would be "io.crates." What is the motivation for introducing this concept of a "group" to the RFC? Why should introduce the ability to acquire "groups" by some means other than the same means by which it divies up its current flat namespace (first come first serve to anyone with a account)? You aren't being very clear about the problem you're trying to solve by introducing this complexity to the feature.

1 Like

(FWIW I've discussed this with @ehiggs out of band and explained some of these differences. I've pointed out areas of their proposal that need to be expanded on, and encouraged them to create a separate thread for their proposal, which i perceive to be significantly different, if they still wish to pursue it. We should probably not discuss this proposal further here unless it can be better tied to the current motivations.)

1 Like

Slight update: I've started moving forward with this as a proper RFC, but haven't posted it yet. In the interest of having things go well, I'm going to let the team discuss this during their meetings first, to work out any remaining issues. Initial signals from them are promising though!


Thank you so much for working on this.

1 Like