In the earlier days of node, when isaac and i were first putting up the registry, we did think about the problems that come with a single global namespace. In the end it was still a better decision to go with a single global namespace for the following reasons.
1. Manufactured Scarcity. The "land grab" that comes with a global namespace may have issues down the line but in the earliest days of the ecosystem is a great incentive to get people publishing modules. 2. Discoverability. We may have *new* discoverability problems today but in the earliest days having one thing be one name is actually a big help for discoverability. Compare this with the early leveldb bindings mess, where Tim Caswell had one thing published, which wasn't the best/latest, that was in someone's fork, and another person had another fork named the same thing but re-written in coffeescript. We have all new problems now because of the size and growth rate of the registry, but we couldn't even have these problems if we didn't get an insane amount of investment already in the ecosystem, investment that was encouraged and benefited from a global namespace. Whatever our new problems are we can't take back the global namespace, it's too far along and too engrained in to how we publish things. Discoverability does suck now, and for entirely other reasons, and Isaac has some good ideas about improving that which I hope to see show up on npmjs.org pretty soon. When we propose new ideas for helping solve the new problems that we have I'd like to put two guiding principals forward. 1. Module problems and people/community problems. 2. Community problems are solved socially more than technically. We can write some great new code that incentivizes people to write "better" modules, we can create better social tools that push us in a direction that suites our own styles and preferences more, but what we can't do is create anything close to "empirical" numbers or ratings that give us the "best" module. At the end of the day someone investing in the community is always going to find better modules than someone who isn't, we can't entirely replace that investment as a tool for discovery but we certainly can make it easier than it is today. -Mikeal On May 28, 2013, at 8:38AM, Michael Schoonmaker <[email protected]> wrote: > I apologize for adding to the "drama", but after reading your comments I > still legitimately believed that what you were arguing towards was muddying > the water between single namespace npm and dual namespace GitHub (whether > through the discovery and search system or the storage is less consequential > to me). I think a non-npm tool like http://eirikb.github.io/nipster/ would be > the most appropriate location, and there's a lot of precedent for these sorts > of tools. > > -Schoon > > P.S. In my case, what produced my answer wasn't the idea, but the > expectations of the existing community and the core team. I'm sure I was just > reading into things, but I want it to be clearer that I don't think people > should keep from sharing these kinds of ideas, albeit with a different set of > expectations. > > > On Tue, May 28, 2013 at 7:11 AM, Marco Rogers <[email protected]> wrote: > At the risk of making things worse, I don't think this is that bad George. I > think the responses you've gotten here have been pretty much in line with > what you asked. You got a little negativity, but not a lot. And it was good > for you to expand on your ideas because your initial message didn't really > convey the right things. This conversation was helpful for me, and I'm sure a > few other people, in thinking about what we could do to move the ecosystem > forward. Lots of people are aware that discoverability sucks and that git > integration is becoming pretty important for lots of people. > > I wish Isaac wouldn't be so quick to drop hammers on people's discussions by > holding forth on what node/npm is or isn't going to do. (I've talked to him > about it, but he's pretty stubborn). I can also see a world where npmjs.org > supported searching a more expanded set of modules. It wouldn't be that > difficult to visually differentiate between modules in the registry and those > located somewhere else. And I actually think it might have some positive > impact in that people would be more aware that they don't have to depend on > what's in the npm registry. It's just one source of modules for the node > ecosystem and there can be others. This is kind of orthogonal to the naming > argument though. I tend to agree with Isaac there. You should name your > modules uniquely. And if that's the only thing that's keeping you from > publishing to the registry, that's a red herring. > > Unfortunately, Isaac has different ideas about what he wants to do with > npmjs.org. And since he is the node police, that means if we want something, > we'll have to either convince him otherwise, or build it outside of what he's > doing. Many people might not know, but they are working on enhancements to > npmjs.org that help with discoverability. If we had more info about what that > looked like, it might give us some ideas. Or people can decide to build their > own thing. Essentially what I'm hearing is you want an extended search index > that includes npm registry modules and github repos that represent node > modules. We'd need to be able to tell the different between the 2, and have a > way to explicitly publish github repos to this system. As Isaac said, this > isn't a trivial undertaking. And people should keep this in mind when they > casually ask for the core team to take on doing something like this. But it's > doable if people really want it and are willing to put in some work. You are > not bound by what the npm core team decides to support. > > :Marco > > > > On Tue, May 28, 2013 at 3:15 AM, George Stagas <[email protected]> wrote: > 2013/5/28 Isaac Schlueter <[email protected]>: > >> How many disputes do you receive per month? > > > > Usually less than 2 per month. But I have no way of knowing how often > > authors talk amongst themselves if they already have some sort of > > relationship. > > > >> Is there a mailing list or something where I can see ownership changes > >> and reasons for such changes? > > > > No. The ownership of an author's modules is their own business. I > > only get involved when absolutely necessary. > > > > > >> 3. a module discovery platform (but sadly, only for the npm registry) > >> Let's just fix #3 to include user/repo projects. > > > > Sorry, George, that's exactly what I'm saying I *won't* do, ever. The > > word "just" there is particularly odd, as if doing so would not > > involve a significant amount of work, or have a significant amount of > > side-effects. On the contrary, it would be a tremendous amount of > > work with wide-ranging side effects. It's never going to happen. > > You're asking for confusion, and I won't do it. > > > > > >> You say you'll be frustrated if you see require('request') and it isn't > >> 'mikeal/request' but I'm equally frustrated when I read 'chaos' 'maga' > >> 'jjw' 'slag' and have to dig in npmjs.org to find out what each one does. > > > > So, then just don't use modules that have stupid names. How is > > "merge" any less vague than "chaos"? What is it merging? Is it for > > doing three-way merges a la git, or merging JS objects, or applying > > patch files, or merging edits from multiple sources using functional > > transforms? I have no way of knowing from that name. > > > > Be as descriptive as you need to, using as many words as necessary, > > until the name is unique. You can always do `var merge = > > require('object-deep-merge')` or `var merge = require('string-merge')` > > or `var merge = require('git-style-three-way-merge')` or `var merge = > > require('merge-patch-file')` or `var merge = > > require('merge-functional-transforms')`. Better discoverability, > > better readability, better debuggability. > > > > I believe that this technique will work for the next several hundred > > million modules, at least. There's a lot of english words, and the > > upper limit on folder name length is very high on most operating > > systems. (On windows, it gets hairy, but Node uses UNC paths by > > default, so it's fine.) > > > > > >> But, since *some* people do want to use gh paths I think it's improper > >> to tell us all that we're wrong and that this is life and we should > >> live with it or keep our projects in our closets because we don't like > >> obscure naming. > > > > I'm not telling you that you're improper for using github paths, or > > that you have to keep your project in your closet. > > > > I'm saying that the npm search is not going to index anything that > > isn't published to npm. I believe that this is a reasonable > > constraint. Want to be in npm search? Pick a name that isn't taken, > > and publish to it. Pretty reasonable trade-off, I think. > > > > I'm also telling you that calling different things by the same name is > > a recipe for unnecessary complexity. > > > > I'm *not* suggesting that you use "obscure" names! That's terrible! > > I'm suggesting that you use *more* descriptive names, which are unique > > in the Node community, and that you publish them to npm, because that > > is the most easy way to share code with the Node community, and > > because discoverability comes with that for free. > > > > If, for some reason, you'd like to pull your code from github instead > > (or any git repo, in fact), then Good News! npm can do that. I often > > point a dependency to a fork of my own while waiting for the author to > > take a patch and publish to npm. But what I don't do is have multiple > > different things with the same vague short name, and I certainly am > > not going to encourage that by having different things with the same > > name showing up in search results on the npm website. > > > > Bottom line: I'm not telling you what to do. *You* can do whatever > > you want. I'm telling you what I'm going to do, and not going to do. > > It's really not negotiable, I'm sorry. > > > > If you want discoverability via npm, then publish to the npm registry, > > with all the constraints that that entails. That's all there is to > > it. > > > > That is awesome and understood, thanks for the descriptive answer. I > was thinking more of an ad-hoc solution that doesn't mess with npm > metadata or the registry, but that is fine, I'll find a way around > this, maybe dual packaging with a long name for npm that depends on > the smaller gh path, or writing an indexing service :) > > Btw, all the drama in this thread could have been avoided, I never > expected this kind of reactions for expressing my apparently unique > thoughts to the world. I will think 1000 times before posting anything > now and I believe others will suffer the same. Thanks to everyone who > contributes to that. > > > > > On Mon, May 27, 2013 at 6:11 AM, Ryan Schmidt > > <[email protected]> wrote: > >> > >> On May 27, 2013, at 03:27, George Stagas wrote: > >> > >>> Good to know about your thoroughly explained arguments but nobody's > >>> suggesting npm or the npm registry namespacing to change. Learn to > >>> read. > >> > >> My enjoyment in reading the discussions in this group is increased when > >> the conversation remains polite, so I'd like to advocate for that. > >> > >> > >> -- > >> -- > >> Job Board: http://jobs.nodejs.org/ > >> Posting guidelines: > >> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines > >> You received this message because you are subscribed to the Google > >> Groups "nodejs" group. > >> To post to this group, send email to [email protected] > >> To unsubscribe from this group, send email to > >> [email protected] > >> For more options, visit this group at > >> http://groups.google.com/group/nodejs?hl=en?hl=en > >> > >> --- > >> You received this message because you are subscribed to the Google Groups > >> "nodejs" group. > >> To unsubscribe from this group and stop receiving emails from it, send an > >> email to [email protected]. > >> For more options, visit https://groups.google.com/groups/opt_out. > >> > >> > > > > -- > > -- > > Job Board: http://jobs.nodejs.org/ > > Posting guidelines: > > https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines > > You received this message because you are subscribed to the Google > > Groups "nodejs" group. > > To post to this group, send email to [email protected] > > To unsubscribe from this group, send email to > > [email protected] > > For more options, visit this group at > > http://groups.google.com/group/nodejs?hl=en?hl=en > > > > --- > > You received this message because you are subscribed to the Google Groups > > "nodejs" group. > > To unsubscribe from this group and stop receiving emails from it, send an > > email to [email protected]. > > For more options, visit https://groups.google.com/groups/opt_out. > > > > > > -- > -- > Job Board: http://jobs.nodejs.org/ > Posting guidelines: > https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines > You received this message because you are subscribed to the Google > Groups "nodejs" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > For more options, visit this group at > http://groups.google.com/group/nodejs?hl=en?hl=en > > --- > You received this message because you are subscribed to a topic in the Google > Groups "nodejs" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/nodejs/mhRUeX8EX2g/unsubscribe?hl=en. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > > For more options, visit https://groups.google.com/groups/opt_out. > > > > > > -- > Marco Rogers > [email protected] | https://twitter.com/polotek > > Life is ten percent what happens to you and ninety percent how you respond to > it. > - Lou Holtz > > -- > -- > Job Board: http://jobs.nodejs.org/ > Posting guidelines: > https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines > You received this message because you are subscribed to the Google > Groups "nodejs" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > For more options, visit this group at > http://groups.google.com/group/nodejs?hl=en?hl=en > > --- > You received this message because you are subscribed to the Google Groups > "nodejs" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/groups/opt_out. > > > > > -- > -- > Job Board: http://jobs.nodejs.org/ > Posting guidelines: > https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines > You received this message because you are subscribed to the Google > Groups "nodejs" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > For more options, visit this group at > http://groups.google.com/group/nodejs?hl=en?hl=en > > --- > You received this message because you are subscribed to the Google Groups > "nodejs" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/groups/opt_out. > > -- -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en --- You received this message because you are subscribed to the Google Groups "nodejs" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
