The lack of namespaces on crates.io is a feature • Hacker News Board

Re: The lack of namespaces on crates.io is a feature

#51

Post by simon_o » Fri, Sep 11, 2020, 5:32 PM UTC

computerphage wrote: post #46

013a wrote: post #24

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 footn…

> 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. This sentence takes the place of a reason. You could have offered a reason why you were right or a rational argument about the matter. Instead, you basically yelled "I'm right, they're wrong! I'm right, they're wrong!".

The GP made nothing more than a prediction about the future.

Let's let the future determine whether he was right or wrong, no need for squabbling.

Re: The lack of namespaces on crates.io is a feature

#52

Post by steveklabnik » Fri, Sep 11, 2020, 5:33 PM UTC

dastbe wrote: post #45

steveklabnik wrote: post #32

Earlier quoted context omitted.

"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.

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 would qualify? Alternative to just removing them, would the crates team be more open to transferring ownership of these packages?

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

Re: The lack of namespaces on crates.io is a feature

#53

Post by andrewzah » Fri, Sep 11, 2020, 5:34 PM UTC

hinkley wrote: post #16

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?

Buglighting. (Bug + gaslighting).

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

Re: The lack of namespaces on crates.io is a feature

#54

Post by hinkley » Fri, Sep 11, 2020, 5:34 PM UTC

gw wrote: post #4

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 j…

Java was my introduction to namespacing, so I only suspected but didn't know for a long time that Java overdid namespacing.

Companies change names, they merge. Sometimes they go out of business but stick around as a foundation stewarding their old projects, and you might be going to example.org for years for documentation on a com.example module.

And the namespaces weren't enforced (who is going to stop me from publishing a com.example.foo module?), so it expected much and delivered little.

No namespaces is bad. Five level namespaces are better, but still bad for different reasons. Two might be good. Some might prefer three. But zero is right out.

Re: The lack of namespaces on crates.io is a feature

#55

Post by papaf » Fri, Sep 11, 2020, 5:35 PM UTC

steveklabnik wrote: post #28

papaf wrote: post #26

Earlier quoted context omitted.

We did look and learn; a lot of crates.io was informed by several of us having experience with CPAN, RubyGems, and npm. Don't those package registries all suffer from not having namespaces? RubyGems in particular [1]. [1] https://thehackernews.com/2020/04/rubygem-typosquatting-malw...

Everything has upsides and downsides. There are downsides to the Rubygems approach. However, typosquatting is an orthogonal problem to namespacing, you can still typosquat a namespace.

From the article:

This is not the first time typosquatting attacks of this kind have been uncovered.

Popular repository platforms such as Python Package Index (PyPi) and GitHub-owned Node.js package manager npm have emerged as effective attack vectors to distribute malware.

"Orthogonal" suggests no connection but what I see above is a list of package managers that don't have namespacing.

Re: The lack of namespaces on crates.io is a feature

#56

Post by steveklabnik » Fri, Sep 11, 2020, 5:35 PM UTC

simon_o wrote: post #48

steveklabnik wrote: post #23

Earlier quoted context omitted.

Maybe. Regardless of what my parent meant, a lot of people in these discussions imply that we never looked at prior art because we did not make the choices around the tradeoff that they wanted us to make. And we did look at many, many approaches. We just decided to not go in those directions.

If your prior art consists of "informed by several of us having experience with CPAN, RubyGems, and npm" it's no surprise that cargo suffers from the issues it currently suffers from.

It is not a comprehensive list of things considered, it is a list of successful ecosystems that we decided to pick something closer to, than others that we decided not to.

And even grouping those together in terms of downsides is not really doing justice to the individual problems that each of those systems deal with.

Re: The lack of namespaces on crates.io is a feature

#57

Post by andylynch » Fri, Sep 11, 2020, 5:37 PM UTC

gw wrote: post #4

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 j…

The team at Sun really got this right.

I recall an interesting precursor in Solaris/ System V - the OS package guidelines recommended using your _stock ticker_ as part of the short name.

Re: The lack of namespaces on crates.io is a feature

#58

Post by kibwen » Fri, Sep 11, 2020, 5:38 PM UTC

013a wrote: post #24

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 footn…

> 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?

Re: The lack of namespaces on crates.io is a feature

#59

Post by hinkley » Fri, Sep 11, 2020, 5:39 PM UTC

andrewzah wrote: post #53

hinkley wrote: post #16

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?

Buglighting. (Bug + gaslighting). "You don't actually have that problem. The system doing that is expressly a feature for you."

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.

Re: The lack of namespaces on crates.io is a feature

#60

Post by steveklabnik » Fri, Sep 11, 2020, 5:40 PM UTC

papaf wrote: post #55

steveklabnik wrote: post #28

Earlier quoted context omitted.

Everything has upsides and downsides. There are downsides to the Rubygems approach. However, typosquatting is an orthogonal problem to namespacing, you can still typosquat a namespace.

From the article: This is not the first time typosquatting attacks of this kind have been uncovered. Popular repository platforms such as Python Package Index (PyPi) and GitHub-owned Node.js package manager npm have emerged as effective attack vectors to distribute malware. "Orthogonal" suggests no connection but what I see above is a list of package managers that don't have namespacing.

They didn't make the claim that no namespaces had anything to do with this, that's an inference you're making from the specific list, when it could be for any number of reasons. For example, these are some of the largest package management ecosystems in the world, so they're more likely to be attacked than smaller ones. (You can of course come back and say that there are other massive ecosystems too, but that's kind of my point: there's more to a discussion than a random article listing a few ecosystems.)

I stated my reasoning in my comment: you can typo squat a namespace, just as easily you can any identifier. I don't see any inherent difference between the two.