
Turn off ri and rdoc generation by default - wlll
https://github.com/rubygems/rubygems/pull/42
======
ef4
This is a classic case of fixing the wrong problem.

The real problem is that installing the documentation is _slow_. If it was
fast, nobody would suggest leaving it out.

Either precompile it, or make the compiler faster.

~~~
telemachos
I disagree. The speed is definitely a big part of the problem, but there is
also space to consider. Yes, drives are big and space is cheap (relative to
many other things), but it's not _nothing_ , and on a production system, there
is zero reason to have the docs take up space.

Additionally, now that we all use bundles, gemsets and who-knows-what to
isolate and manage gems, we get massive, massive duplication. See for example,
the output of this gist: <https://gist.github.com/834302>

~~~
technomancy
> and on a production system, there is zero reason to have the docs take up
> space.

So you're saying the root problem is you haven't configured your production
servers?

~~~
jarin
"Convention over configuration" is one of the central tenets of the Ruby and
Rails communities.

The goal is to have sensible defaults that cover the majority of use cases but
allow deviation when necessary. Since the vast majority of Rubyists almost
never use ri and RDoc locally, DHH is arguing that the default should be to
not install the documentation.

~~~
graywh
I've seen that said about Rails, but never Ruby as a whole.

~~~
jarin
Yeah, they might not come out and say it, but if you look at the majority of
gems that have configuration options they usually assume defaults and you just
configure them if you need something different.

------
steveklabnik
From #ruby-lang a few minutes ago:

    
    
        08:56 < banisterfiend> erikh: the pull request was rejected right?
        08:56 < erikh> banisterfiend: after about 200 people commented on it
        08:57 < erikh> banisterfiend: you know, he's working on a better solution
        08:57 < banisterfiend> i didnt know :)
        08:58 < erikh> nobody fucking asks that first before sending a bunch of 
                       propellerheads to troll though
    

So I guess we'll see something to fix this anyway?

~~~
wlll
From drbrain in the comments:

1.7 will replace --no-rdoc and --no-ri with a single --[no-]document option
(which should be automatically aliased to --[no-]doc by optparse) making this
easier to do.

Not quite the same, if that was what was meant, and calling people who express
a valid opinion on this "propellerheads" just seems unnecessarily insulting.
There are 200+ comments because people feel strongly about this and not
because they are trolling.

~~~
rst
But he's directly refusing to make --no-doc the default, which is the whole
point of the request.

People are complaining about having to install a .gemrc to get sensible
behavior. Making the file a few characters shorter doesn't make it less of a
burden.

~~~
xiaomai
The sensible behavior is to install the documentation., so no .gemrc is
necessary (to get sensible behavior).

~~~
generalk
That's the sensible behavior _if you plan on reading local documentation_.

I can't say I've _ever_ used ri, although I do browse local rdoc, sometimes. I
know plenty of developers that hadn't heard of "gem server" until I mentioned
it. And this is completely discounting production environments, where the
documentation is almost certainly a waste of deploy time.

~~~
rue
Approximately 60% of all questions on #ruby-lang could have been answered by
_ri_ , just for the core and stdlib. It's a shame it doesn't get used more.

It's an orthogonal problem, though. The main issue with doc generation is that
it is really, really slow (compared to the rest of the install process). If it
can be sped up – patches are surely welcome – it'll just leave the envs that
flat-out don't need the docs, ever, and those can use the new --no-doc.

------
wlll
Just to clarify, I realised this was closed when I submitted it, but I feel
it's worth discussion, and the more people who say they don't want it the more
likely it is to get removed at some point in the future, even if it's not
right now.

------
sunkencity
It's insane the rdoc is generated at install on every client machine, if it
was compiled by the author of the gem this would not be a hassle.

I sometimes use the local rdoc, but I have it turned off by default, online
docs are useless when working with older versions of gems.

~~~
JonnieCache
It's even worse when you forget to turn it off server-side. Slow deployments
ahoy!

This is the real problem IMO. Especially as capistrano's bundler module kills
the log output when installing gems in the deployment environment, I bet a lot
of people don't realise that 50% of their deployment time is _generating
docs,_ because they see no direct indication of this on the console output for
capistrano.

~~~
tcopeland
The one constant in my puppet configs:

    
    
      file {
        "/etc/gemrc":
          content => "gem: --no-rdoc --no-ri\n",
          mode    => 644,
          owner   => root,
          group   => root
      }
    

Well, maybe that and ntpd.

------
nestlequ1k
It seems absolutely absurd to me that --no-ri --no-rdoc isn't the default. But
it also doesn't hurt me much since my brain is hardwired to always turn off
rdoc and ri on every machine I install ruby on. Not having to do that anymore
would take away a little part of my soul.

The Rubygems project has been extremely poorly maintained over the years
despite having one of the largest user bases of the Ruby ecosystem. Reminds me
of northern africa. That github pull request might as well be the streets of
Libya.

~~~
technomancy
> The Rubygems project has been extremely poorly maintained over the years
> despite having one of the largest user bases of the Ruby ecosystem.

Have you ever tried to help out? It's understaffed because people like you
would rather complain about it on the Internet than actually improve the
situation.

~~~
riffraff
Also, rubygems has been almost untouched for a long time before the current
mantainers took over, and did a great job of making it more robust and faster

~~~
nirvdrum
I seemed to have a lot fewer problems when 1.3.7 was the status quo. I'm not
looking forward to 1.6 at all. Changing gem activation is certain to cause a
whole mess of problems I've never had to deal with.

------
patrickg
Usually I don't like the "mee too" posts, they always appear childish to me.
But this time I'd also "sign this petition".

~~~
ascendant
Your ideas are intriguing to me and I would like to subscribe to your
newsletter.

~~~
wlll
Usually I don't like the "mee too" posts, they always appear childish to me.
But this time I'd also like to "subscribe to your newsletter".

~~~
Jim_Neath
This isn't Reddit.

