2 ms·
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 wor
by Macha 4y 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/main/reserved_crates 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.
- burntsushi 4y agoI'm not sure I necessarily agree with that... But yeah I specifically did not want to get into what namespaces do solve, and so was instead vague and just acknowledged that they're good for something. :-) 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 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.)
- Macha 4y agoI edited to clarify.