131–140 of 198 posts
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.
Earlier quoted context omitted.
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.
Obviously we're all talking hypotheticals here, but Rust-the-language doesn't need to support crate-level namespaces (which isn't to say that some first-class support couldn't be imagined, but again: hypotheticals). Rust links to libraries (via explicit or implicit `extern crate`) that it finds on the system via the ordinary OS-level library search path mechanism; it's up to the package manager to put those libraries…
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.
But if you lose your domain spreading bad software is the top of my concerns.
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?
This is why I like the Go approach: just use an existing global namespacing system and delegate to it all ownership disputes etc: DNS + actual web servers serving traffic (not necessarily just got repos, since the "vanity imports" offer an indirection based in html meta tags)
Yes, there are benefits to that approach. We rejected it because we want builds to be reproducible, and not to have that property depend on external entities.
I'd like to understand more about the arguments for and against a URL-based module naming / resolution approach. Could you point me to any past discussions on this for further reading?
Earlier quoted context omitted.
Yes, there are benefits to that approach. We rejected it because we want builds to be reproducible, and not to have that property depend on external entities.
Steve, thanks for all your work on Rust! I'd like to understand more about the arguments for and against a URL-based module naming / resolution approach. Could you point me to any past discussions on this for further reading?
I am not 100% sure exactly what you're asking for, so if you could say a teeny bit more than that, that would help me understand what part of the space you're trying to explore. It would also be handy to know what problem you are trying to solve, there are several here.
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, 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…
What are the other possible concerns? The only comments I've seen on this is "It's not any different, people will just squat namespaces" to which I reply: reserve namespaces up front for Rust nursery and bespoke crates.
That has always been the biggest benefit of namespaces, when i type "std.rand" I never have to worry about an attacker squatting "std.rnd". But I could just mistype the namespace! Fine, I could, but all the obvious mistypings could _also_ be reserved!
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…
What concerns? Most people don't care because they feel that the ship has sailed, the mistake is set in the concrete. Transitioning thus becomes the biggest conceivable concern for me. What are the other possible concerns? The only comments I've seen on this is "It's not any different, people will just squat namespaces" to which I reply: reserve namespaces up front for Rust nursery and bespoke crates. That has always…
It seems from your comment (and I may be wrong!) that you're purely talking about the "use namespace to solve squatting" issue, which is only one dimension here. Some people want namespaces and don't care about squatting. Some people want to solve squatting through other means. Some people do see namespaces as a solution to squatting, while others disagree.
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…
Java was my introduction to namespacing, so I only suspected but didn't know for a long time that Java overdid namespacing. Companies change names, they merge. Sometimes they go out of business but stick around as a foundation stewarding their old projects, and you might be going to example.org for years for documentation on a com.example module. And the namespaces weren't enforced (who is going to stop me from publi…
On the other hand I really like how C# and dotnet in general handle the matter. Package namespace are separated from logical (in-code) namespace. Package namespace are usually two/three dotted term, making ownership clear while not bloating the names.
> This is a strike against any namespace system that allows namespace ownership to unexpectedly change. Discontinuous identity has a couple of issues. Hard agree but this has nothing to do with namespaces. This is equally applicable to names in a flat registry. I don't see the point of bringing this up in this article. > there are also real benefits. [...] discourages forks What. How? Why? I guess there's possibly so…
Identity
Continuity
Stability
Squatting
None of these are features, which are incompatible with namespaces. I can't find a compelling reason that Crate works this way in this entire article. The article reads like a list of "why Crate is poorly implemented". Of course, it works when the community is rather young and small. Give it time.