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

61–70 of 198 posts

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

#61

Post by gw »

kibwen wrote: post #47
didibus wrote: post #17

Earlier quoted context omitted.

Agree, Go went a similar route as Java and I think that's good as well. The new tools.deps in Clojure actually is moving to disallow collapsed names for similar reason and will force iglu/iglu. Here's a rationale from them: > The groupId exists to disambiguate library names so our ecosystem is not just a race to grab unqualified names. The naming convention in Maven for groupId is to follow Java’s package naming rule…

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 was a guideline, not a requirement. Cognitect (who makes the clojure CLI tool) doesn't even control clojars, the main clojure maven repo, so they wouldn't be able to enforce that even if they wanted to.

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

#62

Post by steveklabnik »

kibwen wrote: post #58
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 id…

I agree with the main thrust of your post, but there is some level of technical problem because the Rust language doesn't support namespaces in crate names themeselves, and so you have to deal with that (or not...) in some capacity too.

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

#63

Post by papaf »

The_rationalist wrote: post #41
papaf wrote: post #5

I remember when this came up because of the following user: https://crates.io/users/swmon

Why is he not banned / moderated?

I think that, once you start taking down crates and users, you've opened a Pandora's box of responsibility.

The case above is clear but a whole load of not so clear cases would follow and then there would be a need for an appeals process.

My guess is that the developers have better things to do.

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

#64

Post by dastbe »

steveklabnik wrote: post #52
dastbe wrote: post #45

Earlier quoted context omitted.

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

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.

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

#65

Post by kbenson »

simon_o wrote: post #51
computerphage wrote: post #46

Earlier quoted context omitted.

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

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. At least that's generally the consensus of the community here, as I see it.

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

#66

Post by kibwen »

gw wrote: post #49
kibwen wrote: post #39

Earlier quoted context omitted.

> 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? This appears to be using evidence to prove the opposite conclusion; if everyone voluntarily chose to use shorter names, then it means that everyone cares about having shorter names. If there is a more substantial argument for why people have decided that the col…

I didn't choose the shorter names because i "care[d] about having shorter names", i did so defensively, because i figured if i chose `net.sekao/iglu`, someone else would choose `iglu/iglu` which would imply that theirs was the original or official version. Another point i didn't mention is that maven was designed from the start to be decentralized; many companies run their own private maven repos, but also pull artif…

That's a better rationale, although I don't think that really solves your stated problem; as an uninformed user I am still more likely to think that iglu/iglu is the more authoritative source there. Given this, any project that wants to authoritatively own its identifier should probably also register its own top-level namespace... which unfortunately brings us back around to where we started.

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

#67

Post by nitrogen »

PuercoPop wrote: post #33
setr wrote: post #13

Earlier quoted context omitted.

>Forks are inevitable; why would you want to discourage them? The epitome of this mindset I think is "hostile fork" -- the entire notion is nonsensical. The whole point of being FOSS/OSS is the freedom to fork -- by all damn rights, you should fork as you please, and be pleased to fork! The actual problem is not forking.. its community fragmentation, and more importantly loss of a "source of truth". Of course, mainta…

> "hostile fork" -- the entire notion is nonsensical. It is not. It is based in experience. See the xMule/aMule fork. A hostile fork is when the fork project starts bad-mouthing the original project and its maintainers. The notion that forking is by itself hostile is non-sense.

If I'm remembering right, something similar kind of happened with uBlock and uBlock Origin, but it was the original maintainer who came back and forked after the new maintainer became hostile, or something like that.

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

#68

Post by gw »

steveklabnik wrote: post #23
simon_o wrote: post #18

Earlier quoted context omitted.

I think what the GP wanted to say was along the lines of "look at _better_ approaches", not just "look at approaches".

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.

I wasn't even addressing the crates.io team, i was addressing the author of the post.

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

#69

Post by kbenson »

renewiltord wrote: post #7
papaf wrote: post #5

I remember when this came up because of the following user: https://crates.io/users/swmon

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.

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

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

#70

Post by 013a »

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

I am not arguing that this should happen; I am asserting that this will happen. The reasons why it should or shouldn't happen don't matter when it will happen.

If you'd like to: Go back and re-read my comment, but re-read it in the mindframe that I'm against the change. It still holds. I didn't provide reasons why they should make the change, because I don't have a stance on whether they should or shouldn't. I am not qualified to say whether its the "Right" decision; just that Rust is on the wrong side of history with this one.

Post reply on HN