undefined | Better HN

0 pointsMacha3y ago0 comments

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.

0 comments

burntsushi3y ago

I'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

> "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.)

MachaOP3y ago

I edited to clarify.

j / k navigate · click thread line to collapse