Live data from Hacker News

The lack of namespaces on crates.io is a feature

samsieber.tech

191–198 of 198 posts

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

#191
post #177

Earlier quoted context omitted.

"could be tasked with the drudgery of intervening in naming disputes or managing an identity layer" What do these have to do with the issue of namespaces? Having namespaces would lessen naming disputes since users would be able to name their crate whatever. Any system will have disputes, so I'm not sure what the argument is here. I understand why crates uses github for identity management, but it's not ideal that peo…

Once you introduce namespaces, now you have naming disputes about the namespaces themselves.

So? It's still less disputes. Nobody should be taking namespaces such as "http" for example. The namespaces represent who people are, not what the package does.

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

#192

Earlier quoted context omitted.

Either the package manager site allows email resets and the same issue applies, or it doesn’t and you can be locked out forever by forgetting a password. Both failure modes suck.

You're still assuming the domain owner's participation. How many domains lapse while the owner is active and responsive in the community?

You just agreed with my original point that outsourcing identity to DNS/TLS is a good practice!

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

#193

Earlier quoted context omitted.

Well, you don't have to only accept DNS records! It's like arguing that independent email providers shouldn't provide general addresses like @gmail.com or @fastmail.com if they're going to provide any support for custom domains. You could do both . In fact, offering support for custom domains is usually an opportunity to up-sell, particularly to the kind of customers who have already shown that they're willing to spe…

I’m still not sure how that solves the problem, but regardless, the point is that there are many possibilities and tons of complexity. It is not a simple, unambiguous problem with a clear correct answer.

The problem is caused over people squatting on desirable package names, right? Only solves the issue up to the point where people start to squat on desirable namespaces.

If you only develop one or two packages, you don't really care about the squatting issue. Especially if a non-DNS-namespace is free. Light users are generally unaffected by the problem, so they continue to fit within a "free" offering.

Squatting is a non-issue with DNS. Nobody can take your domain from you; effectively, using DNS outsources the control issue to DNS control. The only issue is to guarantee consumers that their builds won't break just because their packages went through forced deprecation when DNS control transferred. The people who suffer from the issue badly enough to need DNS namespacing are either heavy users (who are therefore much more likely to pay) or corporate entities that actually desire a paid option.

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

#194

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.

I'm not sure you followed the above 2 points, or perhaps read them through tinted glasses.

I wasn't arguing that npm's namespacing system is worse than their initial system, nor that their switch to namespacing was a mistake.

The current npm namespaced system, with flaws, is head-and-shoulders better than the previous flat system.

You're saying you did "look and learn". If by that you mean you looked at the end product (npm's is seriously flawed) without looking at the journey to that product (npm's is still a huge improvement over what they started with), then you're not going to learn much from that kind of "looking".

I highlighted Composer/Packagist in a sibling comment as a system you should look and learn from (w.r.t. namespaces).

Choosing to only look at flawed systems that started flat seems like you're just being selective to support your own thesis.

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

#195

Earlier quoted context omitted.

You're welcome! 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.

I should be clear my interest is theoretical. I haven't run into any practical issues with "crates.io" and it's been working great for me. I think the way Go and ES Modules (Deno / browsers) represent module naming and resolution by URLs has some nice benefits: * decentralized module hosting * could be extended beyond HTTP / Git (ie. import modules via "ipfs://") * re-uses existing web infrastructure for namespace ow…

Cool, thanks! So yeah, these decisions were made during the initial implementation, and most of the discussion has only been on one part of this, and so I would say it's an under-explored area. Here's what I've got for you:

1. the only part of this that's been in recent discussions is using the URL as a namespace. This has led to questions around how those are represented in code, given that URLs are not identifiers. Also, using DNS for namespaces is mutable and costs money, this is a huge barrier to adoption that we did not want. Publishing should be free and easy.

2. I think you've already identified some of the tradeoffs that made this be rejected: for reproducible build reasons, referring to external services is considered unacceptable. This is due to stuff like downtime of services we don't control, but also the mutability of those services. In theory, you could proxy them, but it's not as clear what this actually buys you, because to get those advantages back, you'd want to always refer to the proxy, and now you've re-centralized everything.

Another way to look at this is that all of the solutions you've proposed are significantly more complicated than what we've built. That complexity is for good reasons, but given 2, it's not clear that they're good enough to justify the costs. The current situation is significantly simpler for all parties, and the end experience ends up the same anyway.

I hope that helps!

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

#196

Earlier quoted context omitted.

I’m still not sure how that solves the problem, but regardless, the point is that there are many possibilities and tons of complexity. It is not a simple, unambiguous problem with a clear correct answer.

The problem is caused over people squatting on desirable package names, right? Only solves the issue up to the point where people start to squat on desirable namespaces. If you only develop one or two packages, you don't really care about the squatting issue. Especially if a non-DNS-namespace is free. Light users are generally unaffected by the problem, so they continue to fit within a "free" offering. Squatting is a…

For what it's worth, and I don't have a ton of numbers here, the loudest people who want namespaces are people who haven't published a lot of packages, in my estimation. I don't have numbers on that, just gut feels.

> Squatting is a non-issue with DNS.

We must be living on a different web :)

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

#197
post #113

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.

Ok, then how about Maven Central? They give you publishing rights to a particular group ID by verifying your ownership of the corresponding DNS names. They've been around long enough, I think, even if Go hasn't.

Maven Central uses that as a first-time verification (actually, it's OSSRH that requires this, technically there are other ways to publish to Maven Central).

Golang's package system depends on the current DNS records.

With maven, there are plenty of old projects that do not own the domain names for their group ID, and that doesn't cause any problems - they are well-known, established projects, and there's no reason to introduce breaking changes to everyone just because they want to go through some DNS naming changes.

Because of this, there's little reason to fear that if you publish your project today as "io.github.my-project:my-module" you may find yourself having to break all your users if github blocks your account tomorrow (or just changes their URL schema) and you move to gitlab.

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

#198

Earlier quoted context omitted.

I should be clear my interest is theoretical. I haven't run into any practical issues with "crates.io" and it's been working great for me. I think the way Go and ES Modules (Deno / browsers) represent module naming and resolution by URLs has some nice benefits: * decentralized module hosting * could be extended beyond HTTP / Git (ie. import modules via "ipfs://") * re-uses existing web infrastructure for namespace ow…

Cool, thanks! So yeah, these decisions were made during the initial implementation, and most of the discussion has only been on one part of this, and so I would say it's an under-explored area. Here's what I've got for you: 1. the only part of this that's been in recent discussions is using the URL as a namespace. This has led to questions around how those are represented in code, given that URLs are not identifiers.…

That makes sense. Thanks for the info!
Post reply on HN