Pre-RFC: (hyper)minimalist namespaces on crates.io

[bascule]

Aah, indeed, it's ambiguous. Oh well.

[XAMPPRocky]

@kornel

• owner of foo can reserve foo-* .
• The dash naturally matches current practice.
• Prevents namespace exhaustion, because foo-* doesn't squat on foo2-* .
• reservation affects only newly-published crates (i.e. check for namespace ownership is done at cargo publish time, after that it's just a regular crate)
• This allows existing projects to reserve their name prefix for future use without having to fight over existing crates.
• It's very flexible, and it's probably the smallest/easiest way to implement it.

I think using - as the separator and only applying to newly published crates will lead to a very confusing state in the crates.io world. There are a number of serde-* crates not maintained by the serde devs for example. These crates would now be misleading people as to who their maintainers are, and would make the reservation detection harder than needed, since it couldn’t use - as separator in the code, it would at least need to perform a lookup of legacy crates first.

I’d also point out that most people are only ever going to have one, maybe two active projects that merit namespaces, and the people who would benefit most from this feature are the people who are already publishing multiple prefixed crates today. So this not being available to those existing crates really limits its value, and will make a transition to namespaces painful or slow to adopt.

I think as a user if the namespace solution goes down the crates as namespaces route, it should use its own separator, and at some point there should be a way to allow or convert (depending on how it actually works) an existing crate to be a namespace.

[bascule]

@XAMPPRocky

I think as a user if the namespace solution goes down the crates as namespaces route, it should use its own separator

I now agree: after discussing it on the Rust Zulip, it seems adding a new delimiter might not actually be as hard as I thought it would be. See also @withoutboats post above: Pre-RFC: (hyper)minimalist namespaces on crates.io - #13 by withoutboats

Since . is apparently ambiguous everywhere, I now prefer / ala the original packages-as-namespaces proposal. This would also make every existing crate its own namespace, which would be pretty amazing IMO.

[programmerjake]

It would probably be a good idea to allow old crates such as serde-json to add an alias serde/json if the parent crate serde gives permission. this would prevent needing to publish crates twice for any new releases.

[pdolezal]

Maybe just nitpicking, but when talking about convetions, it might be good to clear them first perhaps? Or did I miss something?

[bascule]

@pdolezal

to clear them first

I was deliberately trying to avoid the snake-vs-kebab crate naming debate in this issue.

However, per @withoutboats and @Manishearth, introducing new syntax for this sounds like it's on the table, in which case I think it would definitely make sense to leverage some new delimiter like / as it prevents collisions between crate names and namespace names.

[bascule]

@programmerjake

It would probably be a good idea to allow old crates such as serde-json to add an alias serde/json if the parent crate serde gives permission. this would prevent needing to publish crates twice for any new releases.

This sounds like the "linking" idea from the original packages-as-namespaces proposal. I definitely think it's a "nice to have" but wouldn't look at it as an MVP requirement.

[Manishearth]

@bascule

However, per @withoutboats and @Manishearth, introducing new syntax for this sounds like it's on the table, in which case I think it would definitely make sense to leverage some new delimiter like / as it prevents collisions between crate names and namespace names.

Note: I do not speak for the cargo or crates.io teams. But yeah i have a draft pre-RFC that does this.

[pdolezal]

Yes, it seems to me so.

Anyway, I replied with a suggestion to yours where I intentionally avoid any kind of splitting an existing crate name by some (just) conventions. But I admit I also considered that the typical separators, - and _, should be used to determine the namespace candidates automatically.

[tspiteri]

@kornel

owner of foo can reserve foo-*

Another workaround could be to use two dashes to separate the prefix. So when there is a foo, anyone can create foo-bar, but only the owner of foo can create foo--bar. This avoids the confusion mentioned in another comment:

@XAMPPRocky

I think using - as the separator and only applying to newly published crates will lead to a very confusing state in the crates.io world.

[Manishearth]

edit: I've posted my pre rfc at Pre-RFC: Packages as Optional Namespaces

[kornel]

at least need to perform a lookup of legacy crates first.

I'm specifically avoiding creating a concept of "legacy crates". I think that's an important feature. Rust's stability and network effects mean these "legacy crates" will never disappear. I don't want Rust to have a two-tiered crate ecosystem, and have to forever explain to every new Rust user that there are two kinds of crates, with two naming schemes, and two ownership models. That would be a mess.

If the ownership check was only done at publishing time, then namespaces would not exist as an entity, and would not create two kinds of crates or require incompatible changes.

1. Alice claims foo-* "namespace"
2. Bob tries to create a new crate foo-bobscrate or foo_underscorestoo, but is denied, because foo-* is claimed by Alice.
3. Alice creates foo-alicescrate and it works, and is assigned as the owner of the crate.
4. From that point onwards it's just a regular crate foo-alicescrate as if namespaces didn't exist. Rust/Cargo doesn't need to perform lookup on the foo namespace.

This also gives ability to manage owners per crate, and pass on ownership of individual crates without passing ownership of the whole namespace. I think that's super important.

For example, lets say serde owners claimed serde-* namespace. Carol comes to them and says "I want to make serde-blub2000 for the cool new blub2000 format.". Serde admins can decide they want such crate, create it for Carol, and make her the owner of serde-blub2000, without needing to give her access to all of serde-* and serde-derive and other major crates. Once Carol is made an owner of serde-blub2000 she can publish new versions of that crate herself (but not other serde-foo crates where she's not the owner).

And conversely, maybe JSON stops being cool and serde owners will not want to maintain serde_json any more. If ownership remains per crate, then they can give that crate to someone else to maintain without having to give up all of serde-*.

So reservation gives control. You can register yourcompanyname-* and that is sufficient to ensure nobody will spoof your branded crates.

But it's also flexible. You may want to create an open ecosystem for your project, and act as a mini registrar for yourproject-* crates, which may still be owned and managed by different people.

[XAMPPRocky]

Well I don’t see how that solution addresses how anyone has previously published a serde-* crate would suddenly be required to get permission from the serde devs to continue to publish their already working crates, which is a level of breakage that would be a non-starter for me. Similarly for common prefixes for concepts like http-*, I don’t want to introduce more middlemen acting as arbiters where none are needed. I still think it needs to be a separate new unique identifier or reuse the current ones with a new separator syntax.

[kornel]

Oh, I see the confusion! I phrased it wrong. Let me correct: checked at first publish time, when the crate is crated. Once you're an owner, you can use your ownership as normal.

[Aloso]

So the serde- namespace can be reserved, even though crates starting with serde- already exist and belong to different people? I'm not sure if that is desirable.

[kornel]

This could be solved by adding a rule:

0. if there's an existing crate with prefix being reserved, but you don't own it, then you can't reserve the prefix.

Technically there's no obstacle to doing it one way or another. Personally I think that, at least in the beginning, it'd ease introduction of prefix-namespacing if it allowed to coexist with pre-existing crates. crates.io website could display a note about the pre-existing exceptions "serde-foobar is not owned by serde". Or registration of "already-squatted" prefixes could be blocked, and either the serde project couldn't have a prefix, or they'd have to negotiate with owners of existing serde- crates.