I remember when this came up because of the following user: https://crates.io/users/swmon
Why is he not banned / moderated?
The lack of namespaces on crates.io is a feature
41–50 of 198 posts
Re: The lack of namespaces on crates.io is a feature
#42If 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…
> History is elided, forgotten, then repeated.
This seems like human nature. We continue to do the same thing with client side / Server side rendering. When it comes to computing, we oscillate a lot. In all these cases there is the desired system (lack of namespaces in a way they doesn't absolutely kill you later), we pursue it, we inevitably fail, get burned, revert, forget, repeat.
In the case of namespaces, this is a tale told a thousand times. To the point where I think people don't even want to try to fight for them. What's the point? They shall forge forward, namespace free, until it hurts enough decision makers. Then we get namespaces.
Now, back to Ruby for me. Where anything anywhere can just yolo reach into your namespace and mess your whole life up.
Re: The lack of namespaces on crates.io is a feature
#43Earlier 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.
PHP and it's ecosystem has a lot of problems, but I think Composer/Packagist is as surprisingly exemplary example of how to go about structuring package management.
Re: The lack of namespaces on crates.io is a feature
#44We 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.
That's the 'gold standard' but it leaves it open to interpretation. Some people mean it with very little sense of irony.
Do you think Sam is being ironic with that title, or sincere? His intro is telling us how he's going to calmly explain to us dumb hicks and newbies that we wouldn't know a feature if it bit us on the ass (which it most definitely will, at some point).
The rest of the article doesn't (quite) follow up on that warning, but if you start out by putting everyone on guard nobody is going to listen to you.
Re: The lack of namespaces on crates.io is a feature
#45How 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.
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?
Re: The lack of namespaces on crates.io is a feature
#46If 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!".
Re: The lack of namespaces on crates.io is a feature
#47You 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…
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 different contexts--so who decides who wins?
Re: The lack of namespaces on crates.io is a feature
#48Earlier 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.
If your prior art consists of "informed by several of us having experience with CPAN, RubyGems, and npm" it's no surprise that cargo suffers from the issues it currently suffers from.
Re: The lack of namespaces on crates.io is a feature
#49You 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 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 artifacts from maven central. Having group names reduces the chances of collisions between their private servers and a public maven server.
Re: The lack of namespaces on crates.io is a feature
#50If 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.
A thousand times this.
Why are so many things in software three-steps-forward-two-steps-back?