RubyGems is not a Battlefield, Part I (5/25 meeting w. Eric+Ryan) | Hacker News Reader

RubyGems is not a Battlefield, Part I (5/25 meeting w. Eric+Ryan)

blog.majesticseacreature.com

41 pointssandal12 comments

So refreshing to hear someone do something more than complain.

Interesting. I read it as it being refreshing to hear someone actually listen.

Are the Rubygems folks also looking at Rubygems effect on performance related to require 'foo'? It sounds in this ticket like it may be a ruby problem, but in other places I have seen, it seemed like the IO/file lookups didn't scale well with lots of gems performance-wise.

http://redmine.ruby-lang.org/issues/3924

Unless this is something that has been known to be ignored or rejected otherwise, or unless you feel you can't approach them, I'd just recommend filing a support request or asking on the rubygems-developers mailing list or #rubygems on Freenode.

My main focus is on conflict points right now.

--no-ri --no-rdoc

This is exactly the sort of unhelpful comment that is making the situation worse, not better. There has been a lot of discussion about why RubyGems doesn't support this, and perhaps that discussion got lost in the circus of +1's and tensions. Would you like me to try to get Ryan and Eric to write up something explaining their stance so that you can understand it better?

If you already understand it, would you mind writing a reasoned, well thought out explanation of why you think this is important and then submit a real pull request or discuss this on the rubygems-developers mailing list?

If the answer to those two things is no, then you are not actually contributing, you're stating a preference with no explanation, and no sensitivity to the fact that your personal preference isn't necessarily what's best for Rubygems.

The good news is, RubyGems does has a configuration file which you can set once and solve this problem for yourself. Add this line to your ~/.gemrc:

    gem: --no-ri --no-rdoc

Hopefully this has come across as helpful and not rude. I'm trying the best I can to get both sides of this situation to cool down a bit, and we can help that happen as users and contributors by being a bit more mature about the way we interact with this project.

Gregory,

I think their response is one of the things making the situation worse. If I understand correctly the reasons for keeping it are:

* If documentation isn't generated automatically, where is the incentive to write documentation?

* It's useful for newbies because they can start up `gem server` or use `ri`

So, incentive. Really? I can tell you that of all the code I've written the number of times I've documented it with YARD or RDoc because of a fear that it would be auto-generated on each client and they'd see that is was found wanting is precisely... zero. I document my projects because I want people to use them, I don't want my inbox filled with questions on how to use it, and so I can link to somewhere like rdoc.info where potential users can read it online. I just don't buy that the auto-generation is working like a big scary stick making developers write docs.

As for newbies, I doubt many genuine newbies have any idea of how to use `ri`. Even if they did, you have actually know the class/method you want. At best it's a reference, it's awful for just browsing around trying to piece things together yourself. What I suspect most newbies do is go to Google and enter "How to open a file in ruby", they don't `ri File.new`. The latter assumes a reasonable (albeit forgetful) knowledge of the API, you can assume they're more likely to know about --with-ri rather than the newbies knowing about --no-ri.

The problem here really is that there is a not-insignificant number of people who have all put this setting into their .gemrc file because they want it as the default behaviour. Is it a representative sample of the community? How can we find out? It certainly feels that rather than find out the support for this addition was deemed a "circus of +1's", ignored, and closed.

I makes it had for me to feel sympathy towards the project, reluctant to offer any changes I'd throw around for consideration, and grateful to see others take the initiative to actually fix the problem (you with your mediation, and then SlimGems as a possibly viable alternative).

The --no-rodc --no-ri issue is one I want to reopen for discussion at some point, but I don't think it's as important as many of the other issues that need to be discussed, nor is it urgent.

I agree with you that like many other things, this wasn't handled especially well. I also think that a pull request with hundreds of +1's looks and feels like a riot. That can't be the best way to draw someone's best emotions out of them.

Please send me your thoughts, even if they don't lead to change in the current atmosphere, they will be documented and shared so that if anything does change, there will be a place to find them. Also, you'd be surprised how much of the shutdown comes from these personally charged conflicts. Ryan and Eric have given me an open ear. They should be turning that ear to their whole userbase, but this is a start.

Thanks for the detailed response. I really do appreciate it. To be honest, I wasn't even aware this was possible until I saw DHH's pull request.

Have a few more thoughts. On an iPhone. Not practical to write them all now. Happy to continue dialog though. Aaron@brethorsting.com

Here's how you (and others) can reach me to share your thoughts: http://blog.majesticseacreature.com/mending-the-rubygems-fen...

    $ cat ~/.gemrc 
    ---
    gem: --no-ri --no-rdoc

yw.

Well aware. Still think it should be the default.

Reply on news.ycombinator.com