
The lack of namespaces on crates.io is a feature - LinuxBender
https://samsieber.tech/posts/2020/09/registry-structure-influence/
======
cornstalks
For those not familiar with Rust or the debate around this subject,
"namespace" here is not like a C++ namespace (Rust's modules are analogous to
C++'s namespaces). "namespace" here is about the crates.io package registry,
not the Rust language.

Let's say you have a crate (Rust's terminology for a package) named "foo".
Inside "foo" you have a few subcrates (named "foo_bar", "foo_baz", "foo_qux").
There are a number of situations where a crate will have subcrates. Sometimes
these subcrates are intended to be used publicly (e.g., you want people to be
able to use just the "foo_bar" subcrate if they don't need the whole "foo"
crate) Sometimes these subcrates aren't intended to be used publicly (e.g.,
Cargo forces you to put your proc macro in a separate crate, but that's an
implementation detail of "foo" and isn't something other people should use
directly).

So now you have "foo" on crates.io, as well as a bunch of "foo_*" subcrates on
crates.io. Currently there is nothing stopping some random developer from
publishing their own "foo_haha" crate. This new crate isn't related to your
"foo" crates and might even be squatting on a name you would have liked to use
for a subcrate.

Or multiple people might want to create different crates for similar things.
e.g., there are multiple regular expression crates. But only one of these
crates got the "regex" name. Everyone else has to use a different name, and
sometimes people use creative (unintuitive) crate names.

So for various reasons, some people want namespacing on crates.io that would
allow someone to reserve an entire namespace. This would allow you to prevent
others from using a name that might be confusingly similar to yours. It also
allows you to use conflicting crate names if multiple people want to publish
different crates with the same name.

TL;DR some people want something like npm's scopes for crates.io. And other
people don't want it. This has led to much debate and arguing and whatnot.

It's funny, though, because the team that owns crates.io almost never weighs
in on the discussion, and on the rare occasion that one of the team members
does say something they always do it in a personal capacity and not in a way
that represents the team. This has created its own set of frustrations.

~~~
wnevets
is there a TL;DR for why some people don't want namespaces for crates? Is it
just because NPM does and javascript is bad or is there something else I'm
missing? I couldn't imagine github or npm working well without them.

~~~
steveklabnik
> Is it just because NPM does and javascript is bad

Not at all! In fact, npm's implementation is why some are pro, but also why
some say that it's not worth it; see
[https://news.ycombinator.com/item?id=24444852](https://news.ycombinator.com/item?id=24444852)
for some npm specific sentiment.

(Incidentally, npm added scoped packages in 2015, _after_ these decisions were
made for crates.io. However, crates.io is still smaller than npm was then...)

There isn't really a TL;DR because this space is complex, and there's a lot of
details, and they matter, and different people have different reasons for not
wanting them. I think it's good that github has namespaces, but that doesn't
mean I think that Cargo should have them, because they're fundamentally
different services.

The short reason we gave back in 2014 was:

> Because namespaces are strictly more complicated in a number of ways,and
> because they can be added compatibly in the future should they become
> necessary, we’re going to stick with a single shared namespace.

from [https://internals.rust-lang.org/t/crates-io-package-
policies...](https://internals.rust-lang.org/t/crates-io-package-
policies/1041) which is linked in the post.

~~~
mmis1000
But unlike traditional namespace, that you automatically got alias to things
inside the same namespace.

The npm's namespace is basically just a preserved prefix, mention scoped
package inside another scoped package still requires you to write full name
(scope + package) or it didn't work.

I don't really see a reason that you can't implement it in a flat name package
manager? Something like "you can't publish a package named as
'USERNAME_private_WHATEVER' unless you are USERNAME"

~~~
steveklabnik
Nobody is saying that it's impossible to implement. However, someone would
have to write that up as a plan, including all the details, and put it through
the RFC process, and get folks to agree that that plan is the one that should
be implemented, rather than other possible plans.

------
013a
If there was a sports-like betting site for future decisions that major open
source projects are going to make, I would put a thousand dollars on
"Cargo/Crates will implement namespaces."

The developers have convinced themselves that they're right on this, having, I
suppose, not learned from the hundreds of package managers that have come
before them. They're wrong; full stop, no qualifications, no asterisk, no
footnote, they are totally wrong on this and it is inevitable that their
opinion will change.

But, this is the nature of open source (and even startups). New projects start
under the (oftentimes correct) belief that they can do something better, which
experiences linear extrapolation into believing everything you do is better
through virtue of being unlike what everyone else is doing. We see the end-
state of Maven, NPM, etc; we don't see the war that those projects went
through to reach this state. History is elided, forgotten, then repeated.

~~~
kibwen
_> The developers have convinced themselves that they're right on this_

This is a complete misrepresentation of the issue. Adding namespaces to
crates.io is a social problem, not a technical one, because adding them means
you now must do the work of arbitrating disputes over an identity layer, which
is a job unfit for part-time volunteers, which is all that crates.io has. The
only alternative to arbitrating your own identity layer is to tie yourself to
some other preexisting identity layer (e.g. GitHub, DNS), which raises
questions about the notion of project ownership, the potential transfer of
ownership, the immutability of the package registry, and all the while just
pushes the "race to register" to a different sphere.

If crates.io had full-time employees rather than only volunteers, I'd be all
for paying someone to handle identity problems in exchange for the existence
of namespacing. But who's going to pay for it?

~~~
earthboundkid
> The only alternative to arbitrating your own identity layer is to tie
> yourself to some other preexisting identity layer (e.g. GitHub, DNS)

Devolving identity down to DNS has been a really good decision for Go. I'm not
sure why everyone doesn't do it. It's like XML namespaces, but actually
useful.

~~~
the_mitsuhiko
> Devolving identity down to DNS has been a really good decision for Go

If it works for go, the because go is not old enough. Domain registrations
lapse quickly and then someone else can buy them. That's very close to the
worst that can happen for trust in packages.

~~~
earthboundkid
If you lose your domain, spreading bad software is the least of your concerns.
They can reset all email passwords and access every service you’ve ever used.

~~~
reificator
> _If you lose your domain, spreading bad software is the least of your
> concerns._

But if _you_ lose your domain spreading bad software is the top of _my_
concerns.

~~~
earthboundkid
Either the package manager site allows email resets and the same issue
applies, or it doesn’t and you can be locked out forever by forgetting a
password. Both failure modes suck.

~~~
reificator
You're still assuming the domain owner's participation.

How many domains lapse while the owner is active and responsive in the
community?

~~~
earthboundkid
You just agreed with my original point that outsourcing identity to DNS/TLS is
a good practice!

------
gw
You really should look to other ecosystems and see what lessons they've
learned. In java, packages are normally "namespaced" by the author's reverse
domain name, like `org.lwjgl/lwjgl`.

Since clojure uses maven as well, the same applies, but clojure tools like
leiningen decided to create a shortcut: if the group and artifact name are the
same, like `iglu/iglu`, they can be collapsed into one name: `iglu`

Well, that just encouraged everyone to choose collapsible names. In
retrospect, this didn't buy us much. Who cares about saving a few characters
of typing? Most now seem to agree it wasn't a good idea.

When the "collapsed" name falls out of maintenance, the forks will all seem
somehow less "official", even if they are much higher quality. Forks are
inevitable; why would you want to discourage them?

I finally decided to start using the reverse of my personal domain for my
future libraries. The java folks were right all along.

~~~
steveklabnik
We did look and learn; a lot of crates.io was informed by several of us having
experience with CPAN, RubyGems, and npm. Both the good and the bad.

And also by the experience of going through GitHub hosting a RubyGems server
and all the fallout that happened there.

~~~
lucideer
I have less experience with CPAN and RubyGems but npm's namespacing system has
two very serious problems:

1\. It was introduced very late, meaning the community had already formed
patterns of contribution around a flawed flat system. This is a problem of the
flat system, not of the namespaced one.

2\. It is still to this day entirely optional (for understandable backward
compat. reasons). This gives namespaceless packages a misplaced position of
authority over namespaced ones, which erodes the value of namespacing.

These are tough problems to get around if you start with a flat structure, but
they really just outline the urgency of switching to namespaces for a
relatively young project.

~~~
steveklabnik
I agree with a lot of this perspective. It's also directly relevant to our
situation, because we are basically in exactly that place now, and dealing
with these problems is something that proponents of adding namespaces need to
navigate.

~~~
lucideer
PHP and it's ecosystem has a lot of problems, but I think Composer/Packagist
is as surprisingly exemplary example of how to go about structuring package
management.

~~~
lotyrin
Except for the decision to not tackle solutions for native extensions.

------
kibwen
This article is poorly titled; it's about the lack of namespaces on crates.io.
Rust does have namespaces. Cargo is capable of supporting registries that use
namespaces. Using Rust doesn't even require one to use Cargo, and using Cargo
doesn't require one to use crates.io.

(For the record, I do think that namespaces on crates.io would be a marginal
improvement, but the benefits are often overstated and it would add
organizational costs that the crates.io maintainers can't currently bear. The
amount of ire over this topic is disproportionate to its impact.)

~~~
dang
Ok, we'll use your phrasing above. Thanks!

------
lucideer
> _This is a strike against any namespace system that allows namespace
> ownership to unexpectedly change. Discontinuous identity has a couple of
> issues._

Hard agree but this has nothing to do with namespaces. This is equally
applicable to names in a flat registry. I don't see the point of bringing this
up in this article.

> _there are also real benefits. [...] discourages forks_

What. How? Why?

I guess there's possibly some valid argument for disliking forks (though it's
certainly not put forward in this article), but discouraging them via package
registry structure is... delusional.

Forks are a reality of software and they neither happen as a result of
registry structures, nor can the be discouraged by their designs. They happen
for entirely external, human reasons, and a well-designed registry structure
(i.e. a non-flat one) will be set up to be _resilient_ to forking.

~~~
Supermancho
Aspects of Registry Structure -

Identity

Continuity

Stability

Squatting

None of these are features, which are incompatible with namespaces. I can't
find a compelling reason that Crate works this way in this entire article. The
article reads like a list of "why Crate is poorly implemented". Of course, it
works when the community is rather young and small. Give it time.

------
papaf
I remember when this came up because of the following user:

[https://crates.io/users/swmon](https://crates.io/users/swmon)

~~~
renewiltord
Interestingly, you can't name squat on GitHub. I just asked them for the guy
squatting my first name and they gave it to me. Ah, the power of non-
community-run product. You can do the right thing without having to worry
about the slippery slope.

~~~
kbenson
> I just asked them for the guy squatting my first name and they gave it to
> me.

Your... first name? So "rene" (if I was to assume a few things about your
username)?

~~~
renewiltord
Haha, that's not my real first name. You know, like how Ronaldinho's actual
first name is Ronaldo? Like that. The actual name.

~~~
kbenson
Sure, and that's why I said I was assuming, but my (poorly communicated)
intent was to question how unique your first name is, and how someone is
squatting on it if it's a real account and maybe they have that name too?

I mean, it's probably not a big deal in this case. But if I had a github
account that someone wanted and github just gave out my (personal?) info, I
might feel a bit betrayed by them. I know, I shouldn't give them any info I
really want private, but that doesn't mean I can't expect them to act
responsibly with what I have given them. I just didn't want to state all that
up front, because it assumes a lot about what happened when there wasn't a lot
of detail provided.

It is nice when people can just make simple stuff happen though, I agree. It's
just a hard line to walk, because you allow that and then you get stuff like
the recent Twitter hack. It's hard for us to all have nice things and nice
people that can help us because there really are a bunch of people out there
to get you (or someone in a similar situation, at least). :/

~~~
renewiltord
They don't give you access to the account. They tombstone the old one and
assign its handle to yours. So you get the other GitHub handle but your
account retains its repos, its keys, etc and doesn't get mixed in with the
other account.

Of course, if they just let you login to the other one that would be crazy
business. You'd know the other guy's email for starters. But they don't.

It's all perfectly kosher. You just get the namespace.

~~~
kbenson
Ah, they gave the account name. When you said "asked them for the guy" and
"they just gave it to me", I was interpreting it as the guy's contact info and
them just giving it to you, which is what was raising red flags for me. Yeah,
it's much less problematic if they just let you use the name of a discontinued
account (as long as the github single-sign-on stuff keys off an ID and not a
name, which I assume it does).

~~~
renewiltord
Yeah sorry about that. Though it's funny. You can just scrape folks' repos to
get their email anyway. They all include it in commits. Emails are better made
public than kept private imho.

------
hombre_fatal
It's actually terrible, justs look at NPM and RubyGems.

Instead of just coming up with a good name for your project, you have to come
up with a unique one even though the project with that name isn't even active.
And since most names are taken, you have to come up with a clever one for no
real reason. Or go down the route of naming strats you see on npm/gems:
better-lib, lib2, lib2-better, lib3, better-lib3, etc.

It really does nobody good except for the person who was able to clutch the
original name, and that's a weird incentive structure. Subreddits have this
same problem where you're instantly gimped when named anything other than
r/bitcoin, r/politics, r/news, r/atlanta, etc.

Instead, there should be no preciousness to names nor dictionary words. That's
the correct incentive structure: none.

People keep linking
[https://crates.io/users/swmon](https://crates.io/users/swmon) and it probably
seems like an easy fix to just revoke those names. But swmon isn't the
problem, the system is. It's no bigger problem when swmon does it overtly vs
thousands of people doing it incidentally when they register a package they
don't do anything with.

The problem isn't to calibrate a system that can detect swmon but build a
system where you don't care what swmon does.

What you want is something like this: [https://package.elm-
lang.org/](https://package.elm-lang.org/)

Watching Crates get this wrong was like watching Swift not implement qualified
imports.

------
hinkley
We really need a colorful term for the practice of ‘splaining to people how a
frustrating part of your code is not only not a bug but you are either doing
it (to them) on purpose, or pretending to have done so in order to save face.

Bugsplaining?

~~~
andrewzah
Buglighting. (Bug + gaslighting).

"You don't actually have that problem. The system doing that is expressly a
feature for you."

~~~
hinkley
Hmmm. I admit yours is easier to create an icon for.

Not sure about recognition, or the vaguely defined requirement to avoid Poe's
Law.

------
andrewzah
The lack of namespaces in the crates registry (combined with allowing
squatting) is easily one of the worse aspects of Rust.

~~~
kzrdude
Please elaborate, why?

~~~
andrewzah
Well, what's wrong with namespacing, exactly? Github, java, etc, show us that
namespaces are perfectly fine. Not perfect, but fine.

The rest of Rust is extremely pleasant to work with; a lot of thought has been
put into ergonomics and I love it as a result.

But with crates.io it feels like the opposite. I have to deal with name-
squatting and a much more difficult naming process for crates as pretty much
every short, meaningful name in English is taken at this point. For what
gains? Less forks, less fracturing -in theory-?

I feel like a lot of the arguments for no namespaces are strawmans or make big
stretches. For example, figuring out which fork of a project to use is really
not a problem. And a lack of namespaces does not fix that anyways, because
it's not a code problem... Importing two crates with the same name would be
fairly rare, and rust easily solves that with `use crate::... as ...`. Etc.

Anyway, this discussion has been trod to death. There's no point having it, as
I'll just be told why I'm wrong and why namespaces are just -impossible-.

~~~
kibwen
_> why namespaces are just -impossible-_

As mentioned elsewhere in here, this is a misrepresentation of the issue. The
problem is that crates.io is a free, volunteer-run project with zero full-time
employees who could be tasked with the drudgery of intervening in naming
disputes or managing an identity layer. This is unlike GitHub and unlike
"Java" (by which you probably mean Maven Central, which is operated by
Sonatype). Solve the funding issue first, and then you can start solving the
rest.

~~~
andrewzah
"could be tasked with the drudgery of intervening in naming disputes or
managing an identity layer"

What do these have to do with the issue of namespaces?

Having namespaces would lessen naming disputes since users would be able to
name their crate whatever. Any system will have disputes, so I'm not sure what
the argument is here.

I understand why crates uses github for identity management, but it's not
ideal that people are locked into using one specific git platform. Github is
already an unavoidable entity, much like facebook, but this is a bit of a
harder issue to solve without a lot more resources.

~~~
kibwen
Once you introduce namespaces, now you have naming disputes about the
namespaces themselves.

~~~
sattoshi
So? It's still less disputes. Nobody should be taking namespaces such as
"http" for example. The namespaces represent who people are, not what the
package does.

------
tikhonj
> So what’s a bad actor? I consider someone who squats a bunch of crates to
> make or point or prevent their names from being used to be a bad actor.

In my experience, the thorny problem with namespaces isn't _bad_ actors
because you can fix that with content moderation. Yes, that takes time and
effort which can be scarce in an open-source community, but it's _doable_.

No, the thorny problem is good actors with bad execution: people who publish a
package with a nice name that does what it says it does, more or less, but
does it _poorly_. It doesn't cover all the edges case or it is poorly
optimized or it has limited features or it has some fatal design flaw in its
architecture... Maybe it was fine at some point but just hasn't kept up with
the times.

So what do you do if a package like that grabs the name "json" or "http" or
something? You don't want to kick packages off just for not being _great_ ,
but you also don't want it to seem like the _de facto_ package for a task in
your language. I do a lot of Haskell, and it's not the best developer
experience when you have to tell people "don't use json, use aeson instead".

Namespaces would solve this problem. You could have a "blessed" namespace
(like rust/) and, when functionality becomes important enough that the quality
of the "default" package matters use the namespace to provide that package
(rust/json, rust/http... etc). You don't have to kick off the existing package
(even if it's squatting a "nice" namespace like json/json) but you also don't
get into the point where packages with nice names _look_ fine but are actually
flawed and a bad choice for real work.

------
ithkuil
This is why I like the Go approach: just use an existing global namespacing
system and delegate to it all ownership disputes etc: DNS + actual web servers
serving traffic (not necessarily just got repos, since the "vanity imports"
offer an indirection based in html meta tags)

~~~
steveklabnik
Yes, there are benefits to that approach. We rejected it because we want
builds to be reproducible, and not to have that property depend on external
entities.

~~~
ithkuil
That's orthogonal with the naming scheme. In fact the Go team eventually
implemented a way to decouple the storage of a copy of the package from the
name of the package, namely the goproxy. How they got there was admittedly a
bit clumsy, but it proves that it's possible

~~~
steveklabnik
Sort of; you can still delete github repos and the proxy doesn't keep a copy
forever, right?

~~~
ithkuil
That's an implementarion choice of the proxy. You can run a private proxy that
inplementa whatever policy you want.

If crates wants a policy that stores crates forever then just store crates
forever. What I'm talking about just affects how new crates and new versions
of existing crates get "uploaded".

Imagine you call your crate foo.com/bar. In order to push your crate the
crates server needs to verify that you actually own the foo.com/bar URL.

There are many ways to do that. A simple one is to just have the crates server
pull code from that URL instead of pushing it. If you want to push (e.g. to
work around reachability issues such as firewalls) it's just the matter of
devising one or more ways to prove that you "own" that handle. For example by
serving some challenge response in a html meta tag

~~~
steveklabnik
Right, but then you're back to the exact same issues we're talking about. The
choices made by that proxy is the same discussion we're having here, and also
means you can't _totally_ rely on the external authority for identity, because
you have to manage the mutability in their service. There are many ways to do
it, and that in fact is the exact issue at stake here.

All of the existing services it would make sense to delegate to are more
mutable than we wanted for our system.

~~~
ithkuil
Ok the are many angles to this discussion.

What I wanted to highlight was:

1\. I like a package repository that has "namespaces". In fact that's what I
like about Go approach to package repository from day zero, despite other
rough edges.

2\. Classic approach to "namespacing" like maven's is susceptible to name
squatting or just "split authority": who can claim the "org.apache" org? First
comes, first served? If that doesn't match who owns the apache.org "brand" on
the wider internet, it's not technically a problem of the package repository
but surely it's a practical one.

3\. Name squatting problems exist for DNS too; it's a know problem, with an
existing administration and dispute resolution body, a marketplace and
whatnot. If you cannot get hold of foo.com you'll settle on getfoo.com or
(some abomination like that) and that will be your brand as far as online
presence is concerned. It's only natural for artifacts you want to associate
to that owner to just piggy back on that more prominent identity rather than
have to fight it independently for getfoo.com and perhaps land on gotfoo.com
because getfoo.com has been taken by somebody else.

4\. Now, _if_ you decided that you want namespacing and _given_ the observed
consequences of allowing your users to compete for namespace names
independently of their main online presence, I claim there is a technical
approach that can achieve your stated goal of reproducible builds. The goproxy
is almost what you want. The main different is that the go team aims at a best
effort service and thus want to call it a caching mirror. They could have
chosen to offer a more strict retention guarantee. Go packages are indeed
immutable. The sumdb transparent log is there to enforce that invariant. It's
really just about somebody willing to take the burden of storing the package
bits forever, which is what I understood you choose to do with crates.

~~~
Symbiote
Only apache.org can claim their org.apache on Maven Central. This is checked
the first time you upload a new package.

~~~
ithkuil
Which is exactly my point: if you add such a check you've successfully
delegated naming governance to DNS as you should.

(I do remember maven before that check was implemented and it was chaotic)

------
richardwhiuk
It's not clear why any of the advantages they tout occur because of the lack
of namespaces.

------
wilsocr88
This makes me think of how Python coders say that code is or isn't "Pythonic"

So what would Rusts equivalent be... Rustic? Namespaces are not Rustic.

~~~
ifmpx
> Namespaces are not Rustic

why do you think that?

------
solatic
If anything, namespacing doesn't go far enough. We have a wonderful
namespacing mechanism already for the Internet - it's called DNS. We use DNS
validation as a security foundation for issuing TLS certificates. Package
registries should allow me to "own a domain" \- backed up by DNS validation -
and upload packages under that name. "Domain ownership" should be paired to a
timestamp issued at verification time, so that a) package uploading can be
blocked entirely if the DNS verification is lost, b) consumers can continue to
download packages under the old domain timestamp c) domain ownership can still
transfer as needed d) changes in ownership are tracked, and consumers are
notified.

Why does everybody always have to reinvent the wheel? DNS has been around for
decades. Using DNS records to verify ownership has been around since, what,
the early days of the ACME protocol in 2014/2015? Earlier?

~~~
steveklabnik
DNS records have a financial and technical barrier to account and package
creation that we found unacceptable; and those costs are _ongoing_ , leading
to an unacceptable level of mutability.

~~~
solatic
Well, you don't have to _only_ accept DNS records! It's like arguing that
independent email providers shouldn't provide general addresses like
@gmail.com or @fastmail.com if they're going to provide any support for custom
domains. You could do _both_. In fact, offering support for custom domains is
usually an opportunity to up-sell, particularly to the kind of customers who
have already shown that they're willing to spend money on an on-going basis
(by paying for the DNS name).

~~~
steveklabnik
I’m still not sure how that solves the problem, but regardless, the point is
that there are _many_ possibilities and tons of complexity. It is not a
simple, unambiguous problem with a clear correct answer.

~~~
solatic
The problem is caused over people squatting on desirable package names, right?
Only solves the issue up to the point where people start to squat on desirable
namespaces.

If you only develop one or two packages, you don't really care about the
squatting issue. Especially if a non-DNS-namespace is free. Light users are
generally unaffected by the problem, so they continue to fit within a "free"
offering.

Squatting is a non-issue with DNS. Nobody can take your domain from you;
effectively, using DNS outsources the control issue to DNS control. The only
issue is to guarantee consumers that their builds won't break just because
their packages went through forced deprecation when DNS control transferred.
The people who suffer from the issue badly enough to need DNS namespacing are
either heavy users (who are therefore much more likely to pay) or corporate
entities that actually _desire_ a paid option.

~~~
steveklabnik
For what it's worth, and I don't have a ton of numbers here, the loudest
people who want namespaces are people who haven't published a lot of packages,
in my estimation. I don't have numbers on that, just gut feels.

> Squatting is a non-issue with DNS.

We must be living on a different web :)

------
didibus
I hate namespaces like everyone else, because they're inelegant and kind of
uncool.

dependencies: regex

Vs

dependencies: com.cooladtech/regex

But the world doesn't let us have it elegantly, because the library with the
name "regex" will almost never be the regex library you want to use. It will
almost never happen to be the best, most maintained, best documented, highest
performing, with all the regex features you need library.

So instead, the regex library you want will be called "potato". Like a hot
potato, potato doesn't let you down when parsing regex.

And then there's the issue of groups of packages that generally make sense
together, and no good way to define those groups. So you might have:
regex_core regex_engine and regex_api, but it turns out regex_api is for
another package and not really part of the group.

Anyhow, back to the article...

Identity? So I read and re-read the section on identity, and I'm not sure what
they're saying, it seems they're saying that not having namespaces makes
identity worse for discoverability? So basically it argues for namespaces? Now
I'm confused...

> A flat registry makes identity management (naming a crate) harder

Than for continuity, it seems to say that if you have a namespace it's bad,
because you could confuse two packages of the same name, but in different
namespaces?

Okay, I did see this sometimes, mostly in tutorials where they don't list
their dependencies, but only their import statements (and sometimes they don't
even list the imports). So the reader is kind of left figuring which "regex"
lib they are supposed to choose since it exists in many places.

But then the post also says that the lib name can differ from the package.name
already? Which means you can already have the same lib name for two different
packages in Crates? So I'm confused again?

> Updating to a new package version with different content under different
> ownership is a real security risk

I have no idea how this would happen unless I manually changed the dependency
to point to the one from somewhere else? So I really don't get the risk here.

> Doubly so if you don’t ban new minor versions on the last major version
> after an unintentional ownership change

Okay, hold on a second. I don't think this article is debating what I think
having namespaces mean. Here it seems like the article imagined a world where
you depend on the package name and do not specify a namespace, and then in
crates.io someone could transfer the ownership of the package to someone else.
Or something like that? This makes zero sense to me, I need someone to explain
it to me.

> This is a strike against schemes that encourage multiple distinct crates to
> have the same default name in code. I don’t think any proposal that
> encourages this could be approved.

Okay, now we're talking. This is a GREAT point. Obviously, the import
statement must include the namespace as well. Otherwise you can depend on two
packages and have import conflicts where who knows which module you're
getting? But is this about namespaces? Maybe the argument here is that the way
Rust work, this would not be the case, thus risky? If true, I think this is a
defeating argument honestly, something has to be done about this. Also it
sounds like this is already a problem, because lib name can differ from
package name?

Anyhow, I'd direct people to this amazing post from the Go world, and I think
they got everything right when it comes to their view of package management:
[https://research.swtch.com/vgo-principles](https://research.swtch.com/vgo-
principles)

------
zelly
I'm sorry but a language that has data entropy and link rot built into its
compiler is not appealing to me.

I prefer the Go approach which lets you host or import packages via a HTTP or
git URI. If you have to have packaging built-in to the standard toolchain
these days, then please use already well-known and existing protocols like DNS
and git. Java also figured this out years ago (com.sun... etc).

~~~
steveklabnik
To be clear, you can always depend on a package from your own host, or from a
git URL, today.

~~~
Arnavion
You can also make an alternative registry and add dependencies from that
registry.

That said, an alternative registry that enforces namespacing would not work,
just because of cargo's limitations on package names that prevent characters
like /

It could be done by making every "namespace" a different registry, and for
those registries to allow packages with dependencies from other registries
(something that crates.io doesn't allow, for a reasonably good reason). Would
be quite verbose for the user though.

------
renewiltord
How does crates.io treat bad faith stuff? Like if someone were to make com-
steveklabnik-blog.

~~~
steveklabnik
"bad faith stuff" is not dealt with directly. You could absolutely publish
that crate right now, and I would have no inherent recourse about it.

For the most part, unless a lawyer says that it needs to be taken down, things
aren't taken down. There is a small amount of wiggle room around registering a
large number of packages in an automated fashion, but generally speaking, the
principle is non-intervention.

~~~
dastbe
What qualifies as "a large number of packages"? As was posted in another
thread, it seems like the packages of user
[https://crates.io/users/swmon](https://crates.io/users/swmon) would qualify?

Alternative to just removing them, would the crates team be more open to
transferring ownership of these packages?

~~~
steveklabnik
The focus in that sentence is not "a large number of packages," but the "in an
automated fashion."

Plus, that's only 100 packages. There are people who legitimately maintain
more crates than that.

> would the crates team be more open to transferring ownership of these
> packages?

[https://github.com/rust-lang/rfcs/pull/2614](https://github.com/rust-
lang/rfcs/pull/2614)

~~~
dastbe
Yeah, it's not obvious what the person I linked's intent is. Resale? I'm
pessimistic that the above mechanism would work but I'm glad that rust is
thinking about it.

fwiw I also don't think namespacing necessarily solves this problem, it just
shoves the squatting problem up a level.

------
hevelvarik
I don’t know Rust but have learned enough about it to know that lack of
namespaces in crates.io and anything at all Rust related Is inarguably a
feature

------
gbear0
It sounds like both flat hierarchies and namespaces won't work cause both
sides have fundamental problems that can't be solved in a way that everyone
agrees upon. So what about combining them and having the best of both worlds?
I think the docker namespace schema provides a great way to have a 2 stage
lookup where the first part of the id (up until the last '/') is a full url to
the registry, and the last name in the id is the flat hierachy of names for
that registry.

In fact this scheme is already supported with cargo since you can specify the
registry per dep. This means the default registry, if nothing is added is
'crates.io/' but you can specify any other registry, eg
'gitlab.local/looks/like/namespace' for personal CI, or even
'crates.io/{username}'

Let's give each user their own registry at 'crates.io/{username}'. This works
in a backwards compatible way cause registry:'crates.io/' \+ crate:'mypackage'
is different than registry:'crates.io/mypackage' \+ crate:'mypackage', so
nothing changes with the current crates and it's all an incremental
implementation detail for crates.io

Now we have the npm user style namespace ids that lessens the namesquatting
problem, but increases the security issues if the registry changes hands.
Honestly, I've never really understood the security argument here cause
there's no reason an owner can't hand over a single package. As well, there's
no reason a currently trusted owner can't patch update a package with bad
code. This is a social problem that has no solution and is the same for both
naming systems, so we need to come up with another way of handling things.
Personally I think all published crates should be immutable and all deps
should be pegged, not even allowing patches. But this leads to the argument
that sometimes publishers really do want to take down a crate. I'm on the
fence with this one, so let's try to solve it in another way.

So the problem is we need to potentially remap any (transitive) dependency to
something else, and since we still have a flat hierarchy we really just need
to remap the registry for that dependency. So let's add a registry remapping
section for the cargo deps ... wait cargo already has something for that
([https://doc.rust-lang.org/cargo/reference/source-
replacement...](https://doc.rust-lang.org/cargo/reference/source-
replacement.html)). (Reading through the docs here, it does seems like it
might be a little strict on whether we can use it for this case, but it's
pretty close.)

OK wrapping up, it looks like we could have backwards compatible namespaces
right now if crates.io would just implement user specific registries, ie it's
an implementation detail. And the security issues are really no different than
before. Thus I've got to ask, what am I missing?

