Live data from Hacker News

The lack of namespaces on crates.io is a feature

samsieber.tech

151–160 of 198 posts

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

#151
post #150

Earlier quoted context omitted.

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

That’s just not true though. Rubygems does not, and neither does CPAN, I believe. It doesn't look like PyPi does.

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

#152
post #58
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 id…

Are namespaces somehow more relevant to police than package names?

I don’t see how namespaces would be different?

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

#153
post #65
post #51

Earlier quoted context omitted.

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.

No, their first paragraph was a prediction. Their second was a assertion of fact without any evidence provided. They could have hedged that statement with "I think", or "in my opinion", but instead they went with "They're wrong; full stop, no qualifications, no asterisk, no footnote, they are totally wrong on this". Strong assertions require strong evidence, and not providing that evidence deserves to be called out.…

Every package manager that came before cargo/crates.io is not enough evidence for their assertion?

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

#154

Earlier quoted context omitted.

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

1 is correct, sorta. Comments on an RFC are absolutely fine. That is their purpose. Random forum threads aren't the wrong place for that, like, you can discuss ideas for RFCs on forum threads, but you can't expect the team to always weigh in on threads. Their only responsibility is to the RFC process itself. If you're trying to get a proposal accepted, it's the wrong place. If you're trying to work on a proposal and get early feedback from other people, even if they aren't team members, then it's the right place.

> that still leaves the question of why they haven't made such a RFC yet.

Yes. I speculated a bit in my last paragraph.

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

#155

Earlier quoted context omitted.

Why is he not banned / moderated?

Crates.io is run by a couple volunteers, they (sadly) don't have the time to start playing cat-and-mouse with squatters.

Why isn't Mozilla funding them?

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

#156
post #153
post #65

Earlier quoted context omitted.

No, their first paragraph was a prediction. Their second was a assertion of fact without any evidence provided. They could have hedged that statement with "I think", or "in my opinion", but instead they went with "They're wrong; full stop, no qualifications, no asterisk, no footnote, they are totally wrong on this". Strong assertions require strong evidence, and not providing that evidence deserves to be called out.…

Every package manager that came before cargo/crates.io is not enough evidence for their assertion?

Not if they don't actually mention it, no.

It's not that evidence doesn't exist (it may or may not, and people may or may not agree that something is evidence), it's that none was provided. Without that, all you get is people yelling that they're right and someone else is wrong. Evidence lets people move the argument to useful territory.

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

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

Do we really need to further an already tired meme that only serves purpose to dismiss?

It seems to be doing just fine furthering itself. That’s how this conversation started after all.

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

#158
post #153
post #65

Earlier quoted context omitted.

No, their first paragraph was a prediction. Their second was a assertion of fact without any evidence provided. They could have hedged that statement with "I think", or "in my opinion", but instead they went with "They're wrong; full stop, no qualifications, no asterisk, no footnote, they are totally wrong on this". Strong assertions require strong evidence, and not providing that evidence deserves to be called out.…

Every package manager that came before cargo/crates.io is not enough evidence for their assertion?

> Every package manager that came before cargo/crates.io is not enough evidence for their assertion?

Since not every package manager that came before it is consistent with the assertion, no.

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

#159
post #150

Earlier quoted context omitted.

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.

That’s just not true though. Rubygems does not, and neither does CPAN, I believe. It doesn't look like PyPi does.

There's been some discussion around it for PyPI, but it doesn't seem like there's a consensus that it is necessary, or even on what the set of problems that should be addressed by it is.

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

#160

Earlier quoted context omitted.

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

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.

> If you lose your domain, spreading bad software is the least of your concerns.

OTOH, it's probably higher on the list of downstream code users’ lost of concerns.

> They can reset all email passwords and access every service you’ve ever used

Not if you dealt with all that before letting the domain lapse. And if you don't, more to the point, that's your problem, but not the package manager user communities problem. And that it is a bigger concern of yours than the impacts on the package manager user community is exactly why that community might want to protect themselves from you neglecting their concerns..

Post reply on HN