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.
