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.
The lack of namespaces on crates.io is a feature
151–160 of 198 posts
Re: The lack of namespaces on crates.io is a feature
#152If 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…
I don’t see how namespaces would be different?
Re: The lack of namespaces on crates.io is a feature
#153Earlier 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.…
Re: The lack of namespaces on crates.io is a feature
#154Earlier 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…
> 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
#155Re: The lack of namespaces on crates.io is a feature
#156Earlier 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?
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
#157We 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?
Re: The lack of namespaces on crates.io is a feature
#158Earlier 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?
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
#159Earlier 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.
Re: The lack of namespaces on crates.io is a feature
#160Earlier 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.
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..