8 ms·

I find it absolutely frustrating that Rust packaging/crates.io doesn't support namespaces. The arguments I've read are always theoretical/what ifs, but I've yet

I find it absolutely frustrating that Rust packaging/crates.io doesn't support namespaces. The arguments I've read are always theoretical/what ifs, but I've yet to be convinced the current situation is better than the practical benefits of namespaces.

TheCycoONE 6y ago
Conversely the arguments I've heard for namespaces is that multiple people want to reimplement or make bindings for the same C library. In maven central, in my anecdotal experience, namespaces usually either distinguish forks of the same library, or to group related libraries. There has never been, in my experience, a case where I wanted two packages with the same name in different namespaces. I think a better system of handling unmaintained crates; with the possibility of reclaiming a name would go a long way with the author's use case. I don't have any great ideas here: package with no update in some time (a year?) is eligible. Someone requests to take over name - the author is notified and has a period of time to click an "I'm still here" button. If they don't - new author gets the name. Some 'super version' number is incremented so crate authors opt into the new or old foo. That last part is where I'm the most hesitant.
- mlindner 6y ago
  There's a bigger problem that someone has reserved a ton of common names and they're all empty projects with nothing in them.
  - viraptor 6y ago
    Or even in a non-malicious case: https://crates.io/crates/logger https://crates.io/crates/logger "logger" is now forever a middleware for the iron framework. Same with "router". Iron is pretty much obsolete now.
  - rat87 6y ago
    that sounds like a good thing. It might have been good if the rust team themseleves had pre-squated get rid of all the common names arguments and have everyone use prefixed or unique names
- stefan_ 6y ago
  Of course a single project is very unlikely to depend on two different packages with the same name. But a global repository of all packages is conversely extremely likely to have many many people all wanting one name - it's essentially a .com registry. Reusing project names is just a straight no-go when that is what other peoples projects depend on. As soon as a package has a dependency, (name, version, source) need to be absolutely immutable.
  - boris 6y ago
    As the person you are replying to suggestes, a version epoch could be a solution.
renewiltord 6y ago
Why not `anonova-logger` instead of `logger`. You can namespace by naming if you want.
- j88439h84 6y ago
  One thing is that anonova doesn't control the anonova namespace.
  - renewiltord 6y ago
    Fair enough.
  - rat87 6y ago
    sure but who is going to steal it? it seems easier to do that for the common case then deal with the complexity of namespaces
peacefulhat 6y ago
What do you want to do with namespaces? I don't understand.
- vaylian 6y ago
  give everyone an equal chance to pick a good name
- jgraham 6y ago
  What I personally want from namespaces on crates.io is basically the same as I want from org names on GitHub; the ability to manage permissions at the level of a organistation rather than each package requiring a unique setup, making it harder to audit and admin all the packages belonging to an org. It also seems like a win for consumers to know when they're using code from a specific vendor vs when they aren't. The consumer trust problem you can possibly solve with naming conventions — although it's hard to ensure that everyone has the same conventions unless it's enforced — but the admin problems you can't.
  - DougBTX 6y ago
    Yes, it would be great to have packages grouped by organisation. It would make it much easier to see in a package list how which organisations you're depending on, rather than just how many crates.
- DougBTX 6y ago
  Imagine if every repository you pushed to GitHub had to have a globally unique name, rather than account/whatever-you-like.
  - qayxc 6y ago
    So account-whatever-you-like then?
    - Whitespace 6y ago
      That is not the same, because ownership of _account_ isn't enforced if it's just a string. Imagine someone else uploading qayxc-resume, for example.
ChrisSD 6y ago
How do we decide which person/entity gets a namespace? What about namespace squatting? What if there's a dispute? What do we do about all the currently un-namespaced crates? How would Rust (the language) understand namespaces? How would cargo work with them?
- twic 6y ago
  As a baseline, just do it exactly like in Java/Maven, where it has been absolutely fine for almost twenty years.
  - dthul 6y ago
    I don't know Maven much so please correct me if I'm wrong, but I believe there is a substantial difference: In Maven anybody could publish a package that starts with "com.google". The namespacing proposals I have seen for crates.io assume that namespaces are exclusive to a single entitity though. So once someone that is not Google reserves the "google" namespace, Google itself would not be able to publish crates under that namespace anymore.
    - Quekid5 6y ago
      > In Maven anybody could publish a package that starts with "com.google". I don't think that's the case. If you want to get on Maven Central (at least via SonaType OSS) you have to prove that you own an email address on the relevant domain. If it's your own private package repository, then sure, but then that's not an issue for anybody else.
    - aorth 6y ago
      I just published my first Java package on Maven Central via Sonatype OSSRH this week and when you sign up you have to verify your "groupId" (aka your namespace) using either DNS TXT records or with com.github.username where they ask you to create a repository with a given name to prove you control it. So you could easily publish a package using the com.google namespace on your blog or whatever, but not on Maven Central.
rkangel 6y ago
Everyone complains that 'fuse' is taken so they have to use something with qualifiers (e.g. rust-fuse), and then they propose to fix this with a solution that requires that everyone uses qualifiers for everything. It's a bit more consistent in that no-one gets good names, but is it really such a problem that a few people happened to get in early enough that they could call their library 'fuse'?
- jmillikin 6y ago
  I'm fine with qualifiers, but I don't want useless qualifiers. "rust-" or "-rs" is useless because it's on crates.io. "lib" or "-lib" similarly, unless it's part of a pair with a binary of the same name. Here's a partial list of FUSE server implementations on crates.io: * fuse * cntr-fuse * drakey-fuse * fuse_mt * fuser * fuse-rs * polyfuse * fuse3 * yarf Why do we make people come up with custom prefixes or opaque codenames when they could all be ~user/fuse ?
  - tibbe 6y ago
    Why not user-fuse?
    - deleted 6y ago
      [deleted]
- atombender 6y ago
  Names can be powerful. Owning a name like "fuse" implies that this is the thing called "fuse". A flat "top level" namespace encourages treating names, especially short names, as something with intrinsic value. You end up with the same problems that the .com namespace has, such as name squatting and first mover advantage. Qualifying all names removes this property from names and levels the playing field. There's no value in "owning" github.com/somename/blah. Or, to take the NPM approach, @somename/blah.
  - Macha 6y ago
    But then everyone just wants @fuse/fuse rather than fuse. If one project is @fuse/fuse and the other is @atombender/fuse, the first is going to have more legitimacy, just as if they were called fuse and atombender-fuse.
twic 6y ago
Having namespaces seems like an absolute no-brainer to me, and i find the visceral opposition some people have to it entirely baffling.
rat87 6y ago
what are the practical benefits of namespaces that you don't get with username_logger, username_fuse, etc. ? A lot of the supposed benefits seem like downsides. The ability to have bob_ward/docker and lilly_smith/docker seems like a misfeature I guess you could argue it makes to avoid malicious packages w/ similar spelling but then they could just try the same thing with even less suspicion w/ similarly named namespaces

TheCycoONE 6y ago

Conversely the arguments I've heard for namespaces is that multiple people want to reimplement or make bindings for the same C library. In maven central, in my anecdotal experience, namespaces usually either distinguish forks of the same library, or to group related libraries. There has never been, in my experience, a case where I wanted two packages with the same name in different namespaces. I think a better system of handling unmaintained crates; with the possibility of reclaiming a name would go a long way with the author's use case. I don't have any great ideas here: package with no update in some time (a year?) is eligible. Someone requests to take over name - the author is notified and has a period of time to click an "I'm still here" button. If they don't - new author gets the name. Some 'super version' number is incremented so crate authors opt into the new or old foo. That last part is where I'm the most hesitant.

mlindner 6y ago
There's a bigger problem that someone has reserved a ton of common names and they're all empty projects with nothing in them.
- viraptor 6y ago
  Or even in a non-malicious case: https://crates.io/crates/logger https://crates.io/crates/logger "logger" is now forever a middleware for the iron framework. Same with "router". Iron is pretty much obsolete now.
- rat87 6y ago
  that sounds like a good thing. It might have been good if the rust team themseleves had pre-squated get rid of all the common names arguments and have everyone use prefixed or unique names
stefan_ 6y ago
Of course a single project is very unlikely to depend on two different packages with the same name. But a global repository of all packages is conversely extremely likely to have many many people all wanting one name - it's essentially a .com registry. Reusing project names is just a straight no-go when that is what other peoples projects depend on. As soon as a package has a dependency, (name, version, source) need to be absolutely immutable.
- boris 6y ago
  As the person you are replying to suggestes, a version epoch could be a solution.

renewiltord 6y ago

Why not `anonova-logger` instead of `logger`. You can namespace by naming if you want.

j88439h84 6y ago
One thing is that anonova doesn't control the anonova namespace.
- renewiltord 6y ago
  Fair enough.
- rat87 6y ago
  sure but who is going to steal it? it seems easier to do that for the common case then deal with the complexity of namespaces

peacefulhat 6y ago

What do you want to do with namespaces? I don't understand.

vaylian 6y ago
give everyone an equal chance to pick a good name
jgraham 6y ago
What I personally want from namespaces on crates.io is basically the same as I want from org names on GitHub; the ability to manage permissions at the level of a organistation rather than each package requiring a unique setup, making it harder to audit and admin all the packages belonging to an org. It also seems like a win for consumers to know when they're using code from a specific vendor vs when they aren't. The consumer trust problem you can possibly solve with naming conventions — although it's hard to ensure that everyone has the same conventions unless it's enforced — but the admin problems you can't.
- DougBTX 6y ago
  Yes, it would be great to have packages grouped by organisation. It would make it much easier to see in a package list how which organisations you're depending on, rather than just how many crates.
DougBTX 6y ago
Imagine if every repository you pushed to GitHub had to have a globally unique name, rather than account/whatever-you-like.
- qayxc 6y ago
  So account-whatever-you-like then?
  - Whitespace 6y ago
    That is not the same, because ownership of _account_ isn't enforced if it's just a string. Imagine someone else uploading qayxc-resume, for example.

ChrisSD 6y ago

How do we decide which person/entity gets a namespace? What about namespace squatting? What if there's a dispute? What do we do about all the currently un-namespaced crates? How would Rust (the language) understand namespaces? How would cargo work with them?

twic 6y ago
As a baseline, just do it exactly like in Java/Maven, where it has been absolutely fine for almost twenty years.
- dthul 6y ago
  I don't know Maven much so please correct me if I'm wrong, but I believe there is a substantial difference: In Maven anybody could publish a package that starts with "com.google". The namespacing proposals I have seen for crates.io assume that namespaces are exclusive to a single entitity though. So once someone that is not Google reserves the "google" namespace, Google itself would not be able to publish crates under that namespace anymore.
  - Quekid5 6y ago
    > In Maven anybody could publish a package that starts with "com.google". I don't think that's the case. If you want to get on Maven Central (at least via SonaType OSS) you have to prove that you own an email address on the relevant domain. If it's your own private package repository, then sure, but then that's not an issue for anybody else.
  - aorth 6y ago
    I just published my first Java package on Maven Central via Sonatype OSSRH this week and when you sign up you have to verify your "groupId" (aka your namespace) using either DNS TXT records or with com.github.username where they ask you to create a repository with a given name to prove you control it. So you could easily publish a package using the com.google namespace on your blog or whatever, but not on Maven Central.

rkangel 6y ago

Everyone complains that 'fuse' is taken so they have to use something with qualifiers (e.g. rust-fuse), and then they propose to fix this with a solution that requires that everyone uses qualifiers for everything. It's a bit more consistent in that no-one gets good names, but is it really such a problem that a few people happened to get in early enough that they could call their library 'fuse'?

jmillikin 6y ago
I'm fine with qualifiers, but I don't want useless qualifiers. "rust-" or "-rs" is useless because it's on crates.io. "lib" or "-lib" similarly, unless it's part of a pair with a binary of the same name. Here's a partial list of FUSE server implementations on crates.io: * fuse * cntr-fuse * drakey-fuse * fuse_mt * fuser * fuse-rs * polyfuse * fuse3 * yarf Why do we make people come up with custom prefixes or opaque codenames when they could all be ~user/fuse ?
- tibbe 6y ago
  Why not user-fuse?
  - deleted 6y ago
    [deleted]
atombender 6y ago
Names can be powerful. Owning a name like "fuse" implies that this is the thing called "fuse". A flat "top level" namespace encourages treating names, especially short names, as something with intrinsic value. You end up with the same problems that the .com namespace has, such as name squatting and first mover advantage. Qualifying all names removes this property from names and levels the playing field. There's no value in "owning" github.com/somename/blah. Or, to take the NPM approach, @somename/blah.
- Macha 6y ago
  But then everyone just wants @fuse/fuse rather than fuse. If one project is @fuse/fuse and the other is @atombender/fuse, the first is going to have more legitimacy, just as if they were called fuse and atombender-fuse.

twic 6y ago

Having namespaces seems like an absolute no-brainer to me, and i find the visceral opposition some people have to it entirely baffling.

rat87 6y ago

what are the practical benefits of namespaces that you don't get with username_logger, username_fuse, etc. ? A lot of the supposed benefits seem like downsides. The ability to have bob_ward/docker and lilly_smith/docker seems like a misfeature I guess you could argue it makes to avoid malicious packages w/ similar spelling but then they could just try the same thing with even less suspicion w/ similarly named namespaces