181–190 of 198 posts
Earlier quoted context omitted.
That’s just not true though. Rubygems does not, and neither does CPAN, I believe. It doesn't look like PyPi does.
There's been some discussion around it for PyPI, but it doesn't seem like there's a consensus that it is necessary, or even on what the set of problems that should be addressed by it is.
If anything, namespacing doesn't go far enough. We have a wonderful namespacing mechanism already for the Internet - it's called DNS. We use DNS validation as a security foundation for issuing TLS certificates. Package registries should allow me to "own a domain" - backed up by DNS validation - and upload packages under that name. "Domain ownership" should be paired to a timestamp issued at verification time, so that…
DNS records have a financial and technical barrier to account and package creation that we found unacceptable; and those costs are ongoing , leading to an unacceptable level of mutability.
In fact this scheme is already supported with cargo since you can specify the registry per dep. This means the default registry, if nothing is added is 'crates.io/' but you can specify any other registry, eg 'gitlab.local/looks/like/namespace' for personal CI, or even 'crates.io/{username}'
Let's give each user their own registry at 'crates.io/{username}'. This works in a backwards compatible way cause registry:'crates.io/' + crate:'mypackage' is different than registry:'crates.io/mypackage' + crate:'mypackage', so nothing changes with the current crates and it's all an incremental implementation detail for crates.io
Now we have the npm user style namespace ids that lessens the namesquatting problem, but increases the security issues if the registry changes hands. Honestly, I've never really understood the security argument here cause there's no reason an owner can't hand over a single package. As well, there's no reason a currently trusted owner can't patch update a package with bad code. This is a social problem that has no solution and is the same for both naming systems, so we need to come up with another way of handling things. Personally I think all published crates should be immutable and all deps should be pegged, not even allowing patches. But this leads to the argument that sometimes publishers really do want to take down a crate. I'm on the fence with this one, so let's try to solve it in another way.
So the problem is we need to potentially remap any (transitive) dependency to something else, and since we still have a flat hierarchy we really just need to remap the registry for that dependency. So let's add a registry remapping section for the cargo deps ... wait cargo already has something for that (https://doc.rust-lang.org/cargo/reference/source-replacement...). (Reading through the docs here, it does seems like it might be a little strict on whether we can use it for this case, but it's pretty close.)
OK wrapping up, it looks like we could have backwards compatible namespaces right now if crates.io would just implement user specific registries, ie it's an implementation detail. And the security issues are really no different than before. Thus I've got to ask, what am I missing?
Earlier quoted context omitted.
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.
> If you lose your domain, spreading bad software is the least of your concerns. But if you lose your domain spreading bad software is the top of my concerns.
Earlier quoted context omitted.
DNS records have a financial and technical barrier to account and package creation that we found unacceptable; and those costs are ongoing , leading to an unacceptable level of mutability.
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…
Earlier quoted context omitted.
> If you lose your domain, spreading bad software is the least of your concerns. But if you lose your domain spreading bad software is the top of my concerns.
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.
How many domains lapse while the owner is active and responsive in the community?
Earlier quoted context omitted.
I agree, the Java namespace system isn’t that good. In fact I hate it. First because it uses reverse DNS while common use of URL are in the opposite order. Second because the package sbu-namespace is enforced with the file system structure, which makes for crazy long names. 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.…
> First because it uses reverse DNS while common use of URL are in the opposite order. Well, that's more a bad thing about the DNS though. "toplevel.domainname.subdomain/path" should really be how it should be structured. SUN improved this and made the hierarchy proper.
Earlier quoted context omitted.
> > that still leaves the question of why they haven't made such a RFC yet. > Yes. I speculated a bit in my last paragraph. Sorry, I phrased that poorly; see edit.
> that still leaves the question of why they [edit: the crates.io team] haven't made such a RFC Because as I said before, coming up with an RFC means putting together a viable plan. The team has not come up with a viable plan yet. Therefore, there's no RFC from them. Anyone who feels that they have a viable plan is free to submit an RFC, and then the team will discuss it and give them feedback.
Okay, so it's actually number 2[2], then? Which is a prefectly resonable position, except that it's the opposite of what you said before.
> "The discussion" has often happened outside of the contexts that the teams are supposed to evaluate;
(Also:
> 1 is correct, sorta. Comments on an RFC are absolutely fine. That is their purpose. Random forum threads aren't the wrong place for that, like, you can discuss ideas for RFCs on forum threads, but you can't expect the team to always weigh in on threads.
but I'm not clear on how much of that was attributable to my poor phrasing of 1.)
2: "non-comprehensive discussions [eg, ones lacking a viable plan] are not appropriate for a RFC" https://news.ycombinator.com/item?id=24449289
Earlier quoted context omitted.
> that still leaves the question of why they [edit: the crates.io team] haven't made such a RFC Because as I said before, coming up with an RFC means putting together a viable plan. The team has not come up with a viable plan yet. Therefore, there's no RFC from them. Anyone who feels that they have a viable plan is free to submit an RFC, and then the team will discuss it and give them feedback.
> coming up with an RFC means [I assume: requires, first] putting together a viable plan. Okay, so it's actually number 2[2], then? Which is a prefectly resonable position, except that it's the opposite of what you said before. > "The discussion" has often happened outside of the contexts that the teams are supposed to evaluate; (Also: > 1 is correct, sorta. Comments on an RFC are absolutely fine. That is their purpo…
1. You write up a proposal. We have a template so that you get the structure right and some general prompts to help you ask the right questions.
2. You can post it on the forums, as a "pre-RFC." This is like a vague temperature check from anyone and everyone. Nobody is required to pay attention to these, but it can be a valuable step if they do. This step is optional for everyone involved, you can go straight to step 3.
3. You take your proposal and submit it as an actual RFC. The teams are required to pay attention to these, and they either accept the proposal, reject the proposal, postpone the proposal, or give feedback designed to drive the consensus of the team towards one of these states.
When people say "the team is ignoring threads," they are referring to threads that are in step 2. Most discussions aren't full proposals yet. And they generate a lot of discussion. And then people never move to step 3. Those that do are guaranteed feedback from the team in some fashion.
Your initial edited comment:
> that still leaves the question of why they [edit: the crates.io team] haven't made such a RFC
Nobody is required to make an RFC for anything. If the team doesn't want to write one up, they don't have to. It's on the advocates of the feature to start the process, no matter if they're on the team or not.
> [edit: and told people commenting on the forum threads to instead comment on the RFC, where the crates.io team can evaluate] yet.
They didn't say "comment on the RFC," because there is no RFC at that stage. They said "please make an RFC." This is the same process every single major change to Rust goes through. It's pretty standard. The vast majority of people who desire this feature never actually do it though, because they tend to post on the forums, get a ton of comments from people, and then burn out, it seems.
I hope this helps. To be honest this thread is so old I'm likely to lose track of it and not reply further.
Earlier quoted context omitted.
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?
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 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 ownership (ie. via DNS)
* possibility of hosting backend and frontend modules for multiple languages in a single HTTP registry
* modules may become unresolvable from their original URL (link rot)
* cannot guarantee immutability at the original URL
* semver support becomes a concern of the registry, and some registries may not support it (ie. the logic to resolve "https://example.com/my-module/1.x.x/lib.rs")
* more difficult to discover (browse and search) all available modules
* proxies and dep lockfiles of file hashes to help prevent link rot and immutability
* possibility for open source registry implementations with built-in semver support
* central index of modules which can be searched / browsed, if modules are submitted to it
I'd be very interested in learning more about the costs / benefits of the various approaches and the Rust team's discussions on modules. I really appreciate the team's thorough approach to design decisions, as it's manifested into a really cleanly-designed language.
Thanks!