|
|
|
|
|
|
by Macha
1339 days ago
|
|
|
To me the problem solved by namespaces is making it clear what's an official package of a project and what's a non-malicious third party package intended to work with that project. e.g. bevy and amethyst have claimed a load of crate names like bevy-x or amethyst_y because they thought they might release an official addon to their framework to handle those areas. e.g. bevy did it with this https://github.com/bevyengine/bevy-crate-reservations/blob/m... and amethyst did it the long way as far as I know Organisations wanting to have consistent package names and users wanting to identify related packages are smaller problems than the "all the good names are taken" and "packages can impersonate other packages with typos" problems. |
|
|
I will also say this: at the level of personal preference, and given my understanding of many other package ecosystems, I would have preferred namespaces from the start. But I don't feel very strongly one way or the other to be honest.
There is a related RFC open: https://github.com/rust-lang/rfcs/pull/3243
> "packages can impersonate other packages with typos" problems
I was pointing out that this is specifically not solved at all by namespacing. A package's name includes its namespace, and the namespace can be typo-squatted. (EDIT: Or wait, maybe I'm misunderstanding what you're saying. Perhaps I'm confused by what "these" refers to in your last sentence.)