5 ms·

But how does one avoid having crates.io being flooded by bad/useless crates? And couldn't the same crates end up occupying all the "good" crate names?

by veqz 12y ago

steveklabnik 12y ago
In theory, this could happen. In practice, Ruby/Python/JavaScript seem to be doing just fine.
- fjafjoafjlw 12y ago
  Have you guys given any thought to namespacing packages by developer, like Github. I've had to rename a couple of my own Python packages before uploading them to the package index to avoid naming collisions, so it definitely becomes an issue once the repository hits a certain critical mass. I assume Rust will be around for a while (I certainly hope so - I've just started learning it!) so it might be wise to plan for growth now before it's too late to implement.
  - steveklabnik 12y ago
    It creates a significant amount of complication. When I'm writing a blog post or documentation or in conversation, how do I differentiate between your foo and my foo? When I 'extern crate foo' in my source, which foo should it use? While it's true that sometimes collisions happen, in practice, you just choose a new name. Everything is significantly simpler, which in software is very often a Good Thing.
    - fjafjoafjlw 12y ago
      I can appreciate that it adds complication to the implementation. I don't think identifying a particular crate would be an issue though, any more than identifying a particular repository on Github is. It's easy enough to talk about jdoe/foo if there's any danger of ambiguity, and links are definitive by their nature. Just from my own experience, I know that it makes me less likely to make packages public if I have to give them odd, collision-avoiding names first - especially as I then have to use those names myself. It's particularly annoying when the incumbent package is 10 lines of poorly-written abandonware that hasn't been touched in years, which often seems to be the case. I know this isn't an issue for Rust now but I'm thinking about ten years down the road when you have 250,000 crates on the site, 99.9% of them junk, clogging up that flat namespace. (Python's repository has more than 50,000 packages and seems to be growing at an accelerating rate now that it finally ships with a decent package installer by default.)
      - steveklabnik 12y ago
        > I don't think identifying a particular crate would be an issue though, any more than identifying a particular repository on Github is. Nothing is impossible, of course, but the language already has a flat crate namespace. So you could either implement some kind of layer on top of that, or change the language itself to have some sort of crate hierarchy somehow. All just to have two crates named 'http' rather than one named 'http' and one named 'requests' (for example.) Here's another way of looking at it: shipping a flat namespace is a proven, well-worn solution. Adding in a hierarchical one, on top of the language, which has a flat one, provides dubious benefit, for significant implementation complexity.
        fjafjoafjlw 12y ago
        Meh, if I wanted a 'proven, well-worn solution' I'd use C++. I want you guys to sprinkle fairy dust on my code and make the experience magical ;) Seriously, I do get that there are trade-offs. I'm just interested in how you've been weighing up the alternatives as I do often find myself wishing that other projects I've been involved in had taken the hierarchical approach at the beginning when it was an option.
    - ericolson 12y ago
      Kudos for choosing simplicity where possible. Developers who really like a name could always add something such as using "moz-foo" instead of just "foo". I've been surprised with how few name collision problems I've had on Python's Pypi. If "z-foo" module is more usable than an unmaintained "foo" module, everybody recommends and uses "z-foo" without a second thought.
- veqz 12y ago
  Hmm. If you say so. I'm somewhat uncomfortable with the idea, but I'll gladly defer to people with more experience on this matter than me. Besides, the only alternative I can come up with, is some form of procedure for voting out crates which doesn't play nice with the community...
- hugh4life 12y ago
  Node has a process for dealing with name disputes. https://www.npmjs.org/doc/misc/npm-disputes.html https://www.npmjs.org/doc/misc/npm-disputes.html Not an urgent need, but a similar process will need to be implemented. Naming conventions could be nice too. http://guides.rubygems.org/name-your-gem/ http://guides.rubygems.org/name-your-gem/
  - steveklabnik 12y ago
    Yup, you're absolutely right. There will be processes like these eventually. Naming conventions are currently "the same as Rust identifiers".

But how does one avoid having crates.io being flooded by bad/useless crates? And couldn't the same crates end up occupying all the "good" crate names?

by veqz 12y ago

But how does one avoid having crates.io being flooded by bad/useless crates? And couldn't the same crates end up occupying all the "good" crate names?

steveklabnik 12y ago

In theory, this could happen. In practice, Ruby/Python/JavaScript seem to be doing just fine.

fjafjoafjlw 12y ago
Have you guys given any thought to namespacing packages by developer, like Github. I've had to rename a couple of my own Python packages before uploading them to the package index to avoid naming collisions, so it definitely becomes an issue once the repository hits a certain critical mass. I assume Rust will be around for a while (I certainly hope so - I've just started learning it!) so it might be wise to plan for growth now before it's too late to implement.
- steveklabnik 12y ago
  It creates a significant amount of complication. When I'm writing a blog post or documentation or in conversation, how do I differentiate between your foo and my foo? When I 'extern crate foo' in my source, which foo should it use? While it's true that sometimes collisions happen, in practice, you just choose a new name. Everything is significantly simpler, which in software is very often a Good Thing.
  - fjafjoafjlw 12y ago
    I can appreciate that it adds complication to the implementation. I don't think identifying a particular crate would be an issue though, any more than identifying a particular repository on Github is. It's easy enough to talk about jdoe/foo if there's any danger of ambiguity, and links are definitive by their nature. Just from my own experience, I know that it makes me less likely to make packages public if I have to give them odd, collision-avoiding names first - especially as I then have to use those names myself. It's particularly annoying when the incumbent package is 10 lines of poorly-written abandonware that hasn't been touched in years, which often seems to be the case. I know this isn't an issue for Rust now but I'm thinking about ten years down the road when you have 250,000 crates on the site, 99.9% of them junk, clogging up that flat namespace. (Python's repository has more than 50,000 packages and seems to be growing at an accelerating rate now that it finally ships with a decent package installer by default.)
    - steveklabnik 12y ago
      > I don't think identifying a particular crate would be an issue though, any more than identifying a particular repository on Github is. Nothing is impossible, of course, but the language already has a flat crate namespace. So you could either implement some kind of layer on top of that, or change the language itself to have some sort of crate hierarchy somehow. All just to have two crates named 'http' rather than one named 'http' and one named 'requests' (for example.) Here's another way of looking at it: shipping a flat namespace is a proven, well-worn solution. Adding in a hierarchical one, on top of the language, which has a flat one, provides dubious benefit, for significant implementation complexity.
      - fjafjoafjlw 12y ago
        Meh, if I wanted a 'proven, well-worn solution' I'd use C++. I want you guys to sprinkle fairy dust on my code and make the experience magical ;) Seriously, I do get that there are trade-offs. I'm just interested in how you've been weighing up the alternatives as I do often find myself wishing that other projects I've been involved in had taken the hierarchical approach at the beginning when it was an option.
  - ericolson 12y ago
    Kudos for choosing simplicity where possible. Developers who really like a name could always add something such as using "moz-foo" instead of just "foo". I've been surprised with how few name collision problems I've had on Python's Pypi. If "z-foo" module is more usable than an unmaintained "foo" module, everybody recommends and uses "z-foo" without a second thought.
veqz 12y ago
Hmm. If you say so. I'm somewhat uncomfortable with the idea, but I'll gladly defer to people with more experience on this matter than me. Besides, the only alternative I can come up with, is some form of procedure for voting out crates which doesn't play nice with the community...
hugh4life 12y ago
Node has a process for dealing with name disputes. https://www.npmjs.org/doc/misc/npm-disputes.html https://www.npmjs.org/doc/misc/npm-disputes.html Not an urgent need, but a similar process will need to be implemented. Naming conventions could be nice too. http://guides.rubygems.org/name-your-gem/ http://guides.rubygems.org/name-your-gem/
- steveklabnik 12y ago
  Yup, you're absolutely right. There will be processes like these eventually. Naming conventions are currently "the same as Rust identifiers".