Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The lack of namespaces on crates.io is a feature

samsieber.tech

Post reply on HN
Print view View original

141–150 of 198 posts

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

#141

Post by ithkuil »

steveklabnik wrote: post #116
ithkuil wrote: post #114

Earlier quoted context omitted.

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

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

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.

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

#142

Post by Symbiote »

didibus wrote: post #111
kibwen wrote: post #47

Earlier quoted context omitted.

Can I get a link to the quoted document? The quote raises more questions than it answers. Who determines that someone applying for a qualified name is the owner of that trademark (presumably this is a full-time employee; who pays their salary?), and what is the process? Trademarks are not a universal namespace--even within a single legal jurisdiction you can have the same name legally owned by different people due to…

The quote is from: https://insideclojure.org/2020/07/28/clj-exec/ under section "Deprecated unqualified lib names". That said, ya this is best intentions unfortunately. I'm guessing if you own a real trademark, you could actually sue people using your trademark as their group-id. Otherwise in general they recommend using a registered web domain name. Someone else could take over your domain name as theirs, but I thin…

> maven-central required a form of proof of ownership of the domain

They do. There's even a manual review procedure.

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

#143

Post by Symbiote »

hinkley wrote: post #54
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 publi…

The Maven Central repository will not allow you to publish a Java package com.example.foo.

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

#144

Post by Symbiote »

ithkuil wrote: post #141
steveklabnik wrote: post #116

Earlier quoted context omitted.

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

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

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

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

#145

Post by [deleted] »

ithkuil wrote: post #141
steveklabnik wrote: post #116

Earlier quoted context omitted.

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

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

[deleted]

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

#146

Post by ithkuil »

Symbiote wrote: post #144
ithkuil wrote: post #141

Earlier quoted context omitted.

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

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

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)

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

#148

Post by 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.

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

#149

Post by a1369209993 »

steveklabnik wrote: post #129
krainboltgreene wrote: post #124

Earlier quoted context omitted.

I mean while I absolutely understand the latter situation, the former doesn't feel as understandable because the team could just...make an rfc for it. If you community is clamoring about something, but no one has stepped up to make an RFC for the situation, you have to do two things: 1. Make an RFC for the clamor 2. Figure out why no one has done this already As you know, the lack of response is as much a response as…

"Make an RFC" means coming up with a comprehensive plan for implementing the feature. If the team says "hey we're not sure we've ever seen a plan that addresses our problems," then it's not really their job to figure out how to address those problems, it's the people who actually want the feature. That may be the team, of course, if they think that it is important enough to pursue. There are people who actively do no…

> "Make an RFC" means coming up with a comprehensive plan for implementing the feature.

That directly contradicts your previous comment (that RFCs are the contexts that the teams are supposed to evaluate). Either:

1: non-comprehensive discussions are appropriate for a RFC, and random forum threads are the wrong place for that, in which case your previous comment is absolutely correct that it's unnecessary and likely counterproductive for the crates.io team to weigh in on said threads, but that still leaves the question of why they [edit: the crates.io team] haven't made such a RFC [edit: and told people commenting on the forum threads to instead comment on the RFC, where the crates.io team can evaluate] yet.

Or:

2: non-comprehensive discussions are not appropriate for a RFC, and should take place elsewhere (ie random forum threads), in which case it's completely reasonable to expect normative (but obviously not binding) feedback on what would be necessary to produce a RFC-quality proposal in the first place.

Personally I weakly favor the former view, on the basis that RFC literally stands for "Requests For Comment", but either one would be a sensible position, as long as one doesn't try to assert the negation simultaneously.

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

#150

Post by Aeolun »

steveklabnik wrote: post #30
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, 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. Comments like this are why this discussion has devolved over the years. It's "all heat and no lig…

I think the point of the post is that whatever the reason, every other package manager that has started out without namespaces has eventually implemented them.

The reasons may be unclear, but it seems likely that eventually the crates.io team will receive the same reasons that the other package managers got and implement namespaces.

Post reply on HN