Live data from Hacker News

The lack of namespaces on crates.io is a feature

samsieber.tech

31–40 of 198 posts

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

#32

How does crates.io treat bad faith stuff? Like if someone were to make com-steveklabnik-blog.

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

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

#33
post #13
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…

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

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

#36

Earlier quoted context omitted.

I have less experience with CPAN and RubyGems but npm's namespacing system has two very serious problems: 1. It was introduced very late, meaning the community had already formed patterns of contribution around a flawed flat system. This is a problem of the flat system, not of the namespaced one. 2. It is still to this day entirely optional (for understandable backward compat. reasons). This gives namespaceless packa…

I agree with a lot of this perspective. It's also directly relevant to our situation, because we are basically in exactly that place now, and dealing with these problems is something that proponents of adding namespaces need to navigate.

This is the only good argument I've heard yet for not adding namespace. And maybe it's a defeating argument, maybe Crates is doomed to not have namespace due to the cost of putting them in after the fact.

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

#37

How does crates.io treat bad faith stuff? Like if someone were to make com-steveklabnik-blog.

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

Cool. I guess there's no real reason to solve a problem till it's a problem. Hasn't hurt me yet so optimizing for adoption doesn't seem so bad.

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

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

"It's not a bug it's a feature" is the phrase I usually see thrown about for things like this.

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

#39
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…

> 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 collapsing was mistake, I'd like to read it.

Post reply on HN