[Pre-RFC]: Packages as Namespaces


#22

@carols10cents, the note about permissions is a really good one. I had definitely planned to flesh the permissions model out more in the full proposal. I think @icefoxen’s point about basically trusting the maintainers of a top level package to manage their own community is a good one. Selecting good defaults is probably the key thing for this RFC.

With respect to user research, I think that looking at why npm adopted scopes can provide a lot of value. They have already done some of the legwork about this sort of thing and talked about it in the open, so that’s great. I started this discussion because of the flood of chatter about this stuff on /r/rust and other boards, and I think those discussions can also be mined.

I promise I’ll write up the actual RFC real soon now.


#23

If we did have multi-level nesting, I wonder if it could start one level up with the registry. In order words: @foo/bar would be short for @cratesio/foo/bar and registries would just be namespaces that happened to have their own URL.


#24

Sourcegraph search of the index for __

repo:^github\.com/rust-lang/crates\.io-index$ __

One crate, teardown_tree___treap, which is

Do not use - intended for internal use of teardown_tree crate

Which seems like it would enjoy being teardown_tree/treap instead?

This is the singular occurrence of a double underscore in the index, and is indeed a triple underscore.

(This post is merely meant to be informative and not issue support one way or another)


#25

Awesome datapoint!


#26

An interesting use of namespaces would be to relax orphan rules. This RFC states that nobody can write diesel-chrono crate that integrates the two crates that would like to stay independent of each other.

However, if there was diesel:bike:chrono namespaced crate, then it would be known that all the diesel:bike:* crates are from the same author/owner/org, so they would have power to enforce their own orphan rules across their own crates.

This way the diesel crate could remain abstract and not depend on chrono, and the diesel:bike:chrono could add chrono support by being privileged to implement traits that currently only diesel can.


#27

As an FYI, crates.io team member here, I worked for npm for 3 years. I have been and intend to continue sharing the best practices I learned from that team. If you have any questions, feel free to direct them to me.

As for why name spaces were originally introduced, it was to help create a paid product, private packages. Very few people used them, until around 2 years later when we introduced another paid product, organizations. Free and paid organizations are the primary use case that folks use and it’s largely as a result of the increased and more ergonomic permissions controls. crates.io already affords this by letting folks leverage GitHub teams. So strictly from a npm point of view, crates.io does not currently have a motivation for this feature as we don’t need to make money and already give folks the ability to organize permissions via GitHub organizations.


#28

Background: crates.io team member, npm engineer 3 years

I’d like to share that package disputes on npm are handled by a rather large team of paid support engineers. Disputes are by far the largest time burden they have. They are handled manually. I believe, through my discussions with Bundler/RubyGem maintainers that they do not have this policy because they cannot support a support team large enough to thoughtfully handle these requests.

At the moment, the crates.io team also does not have this set of support engineers. Until the team is able to grow (I have advertised joining the team multiple times in the past few weeks with literally zero people taking me up on the offer), I cannot imagine how we would be able to take on the workload of supporting this.


#29

That’s a cool point about orphan rules. I think I’m not going to address it in the proposal I put forward, but if optional package based namespaces are adopted it would be a cool follow up.


#30

@ag_dubs, that sounds like a point in favor of this idea. Hopefully optional namespaces would reduce the number of disputes that could come up and take some of the burden off the crartes.io team.

Until the team is able to grow (I have advertised joining the team multiple times in the past few weeks with literally zero people taking me up on the offer), I cannot imagine how we would be able to take on the workload of supporting this.

I’m a little confused about what you mean my this. Are you talking about the code changes required to allow crates.io to understand namespaces? I’m not proposing any sort of dispute resolution mechanism, so this proposal would not impose any sort of mandate on anyone to start playing judge.


#31

I suggested a more aggressive name spacing using epochs here:


#32

Best namespaces proposal so far. One addition: would be great to let owner of the “parent” namespace to add collaborators who also have right to publish/edit their crates.


[Pre-RFC] Domains as namespaces
[Pre-RFC] Domains as namespaces
#33

Does anyone have thoughts on what to do about name mangling? I’ve been trying to figure out how the module path separator is mangled currently, but I didn’t find any quick answer.