Aah, indeed, it's ambiguous. Oh well.
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.
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
. 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.
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.
Maybe just nitpicking, but when talking about convetions, it might be good to clear them first perhaps? Or did I miss something?
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.
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.
Note: I do not speak for the cargo or crates.io teams. But yeah i have a draft pre-RFC that does this.
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,
_, should be used to determine the namespace candidates automatically.
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:
edit: I've posted my pre rfc at Pre-RFC: Packages as Optional Namespaces
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.
- Alice claims
- Bob tries to create a new crate
foo_underscorestoo, but is denied, because
foo-*is claimed by Alice.
- Alice creates
foo-alicescrateand it works, and is assigned as the owner of the crate.
- From that point onwards it's just a regular crate
foo-alicescrateas if namespaces didn't exist. Rust/Cargo doesn't need to perform lookup on the
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-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
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.
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.
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.
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.
This could be solved by adding a rule:
- 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.