I hate namespaces like everyone else, because they're inelegant and kind of uncool. dependencies: regex Vs dependencies: com.cooladtech/regex But the world

I hate namespaces like everyone else, because they're inelegant and kind of uncool. dependencies: regex Vs dependencies: com.cooladtech/regex But the world doesn't let us have it elegantly, because the library with the name "regex" will almost never be the regex library you want to use. It will almost never happen to be the best, most maintained, best documented, highest performing, with all the regex features you need library. So instead, the regex library you want will be called "potato". Like a hot potato, potato doesn't let you down when parsing regex. And then there's the issue of groups of packages that generally make sense together, and no good way to define those groups. So you might have: regex_core regex_engine and regex_api, but it turns out regex_api is for another package and not really part of the group. Anyhow, back to the article... Identity? So I read and re-read the section on identity, and I'm not sure what they're saying, it seems they're saying that not having namespaces makes identity worse for discoverability? So basically it argues for namespaces? Now I'm confused... > A flat registry makes identity management (naming a crate) harder Than for continuity, it seems to say that if you have a namespace it's bad, because you could confuse two packages of the same name, but in different namespaces? Okay, I did see this sometimes, mostly in tutorials where they don't list their dependencies, but only their import statements (and sometimes they don't even list the imports). So the reader is kind of left figuring which "regex" lib they are supposed to choose since it exists in many places. But then the post also says that the lib name can differ from the package.name already? Which means you can already have the same lib name for two different packages in Crates? So I'm confused again? > Updating to a new package version with different content under different ownership is a real security risk I have no idea how this would happen unless I manually changed the dependency to point to the one from somewhere else? So I really don't get the risk here. > Doubly so if you don’t ban new minor versions on the last major version after an unintentional ownership change Okay, hold on a second. I don't think this article is debating what I think having namespaces mean. Here it seems like the article imagined a world where you depend on the package name and do not specify a namespace, and then in crates.io someone could transfer the ownership of the package to someone else. Or something like that? This makes zero sense to me, I need someone to explain it to me. > This is a strike against schemes that encourage multiple distinct crates to have the same default name in code. I don’t think any proposal that encourages this could be approved. Okay, now we're talking. This is a GREAT point. Obviously, the import statement must include the namespace as well. Otherwise you can depend on two packages and have import conflicts where who knows which module you're getting? But is this about namespaces? Maybe the argument here is that the way Rust work, this would not be the case, thus risky? If true, I think this is a defeating argument honestly, something has to be done about this. Also it sounds like this is already a problem, because lib name can differ from package name? Anyhow, I'd direct people to this amazing post from the Go world, and I think they got everything right when it comes to their view of package management: https://research.swtch.com/vgo-principles https://research.swtch.com/vgo-principles