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 <gsta...@gmail.com> wrote:
> 2013/5/28 Isaac Schlueter <i...@izs.me>:
> >> 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
> > <google-2...@ryandesign.com> 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 nodejs@googlegroups.com
> >> To unsubscribe from this group, send email to
> >> nodejs+unsubscr...@googlegroups.com
> >> 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 nodejs+unsubscr...@googlegroups.com.
> >> 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 nodejs@googlegroups.com
> > To unsubscribe from this group, send email to
> > nodejs+unsubscr...@googlegroups.com
> > 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 nodejs+unsubscr...@googlegroups.com.
> > 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 nodejs@googlegroups.com
> To unsubscribe from this group, send email to
> nodejs+unsubscr...@googlegroups.com
> 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
> nodejs+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
--
Marco Rogers
marco.rog...@gmail.com | 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 nodejs@googlegroups.com
To unsubscribe from this group, send email to
nodejs+unsubscr...@googlegroups.com
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 nodejs+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
