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

http://blog.majesticseacreature.com/rubygems-is-not-a-battlefield-part-1-notes-fr

by sandal • 15 years ago

41 12 15 years ago

blog.majesticseacreature.com

technomancy• 15 years ago

So refreshing to hear someone do something more than complain.

nirvdrum• 15 years ago

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

aaronbrethorst3• 15 years ago

--no-ri --no-rdoc

ichverstehe• 15 years ago

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

yw.

aaronbrethorst3• 15 years ago

Well aware. Still think it should be the default.

sandal4• 15 years ago

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.

aaronbrethorst3• 15 years ago

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

glenngillen• 15 years ago

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).

ericb• 15 years ago

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

sandal4• 15 years ago

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.

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

Related Stories