6 ms·

Turn off ri and rdoc generation by default

86 points by wlll 16y ago

wlll 16y ago
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 16y ago
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 16y ago
  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 16y ago
    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.
- jarin 16y ago
  It's a pain when you're using rvm too, you end up with a copy of the docs for every gemset.
patrickg 16y ago
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 16y ago
  Your ideas are intriguing to me and I would like to subscribe to your newsletter.
  - wlll 16y ago
    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 16y ago
      This isn't Reddit.
steveklabnik 16y ago
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 16y ago
  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.
  - steveklabnik 16y ago
    I also think that it's a bit excessive. Some people seem to get frothy at the mouth when they see 'dhh.'
    - deleted 16y ago
      [deleted]
  - rst 16y ago
    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 16y ago
      The sensible behavior is to install the documentation., so no .gemrc is necessary (to get sensible behavior).
deleted 16y ago
[deleted]
ef4 16y ago
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 16y ago
  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 https://gist.github.com/834302
  - technomancy 16y ago
    > 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?
    - telemachos 16y ago
      > So you're saying the root problem is you haven't configured your production servers? I'm not sure what you mean. If you mean "It's trivial to add 'gem: --no-ri --no-rdoc' to your .gemrc file. It's your fault if you haven't configured your server correctly.", then you're avoiding the point of this argument. We all agree that you can change defaults. We're discussing what the default should be.
      - technomancy 16y ago
        The default should be what makes sense in a development environment, since rubygems is a development tool. The fact that you can use it to perform deployments as well is interesting, but doesn't concern this question. Generating both HTML and console documentation is suspect, but generating no documentation at all is much worse.
nestlequ1k 16y ago
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 16y ago
  > 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 16y ago
    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 16y ago
      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.

86 points by wlll 16y ago

wlll 16y ago

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 16y ago

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 16y ago
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 16y ago
  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.
jarin 16y ago
It's a pain when you're using rvm too, you end up with a copy of the docs for every gemset.

patrickg 16y ago

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 16y ago
Your ideas are intriguing to me and I would like to subscribe to your newsletter.
- wlll 16y ago
  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 16y ago
    This isn't Reddit.

steveklabnik 16y ago

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 16y ago
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.
- steveklabnik 16y ago
  I also think that it's a bit excessive. Some people seem to get frothy at the mouth when they see 'dhh.'
  - deleted 16y ago
    [deleted]
- rst 16y ago
  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 16y ago
    The sensible behavior is to install the documentation., so no .gemrc is necessary (to get sensible behavior).

deleted 16y ago

[deleted]

ef4 16y ago

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 16y ago
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 https://gist.github.com/834302
- technomancy 16y ago
  > 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?
  - telemachos 16y ago
    > So you're saying the root problem is you haven't configured your production servers? I'm not sure what you mean. If you mean "It's trivial to add 'gem: --no-ri --no-rdoc' to your .gemrc file. It's your fault if you haven't configured your server correctly.", then you're avoiding the point of this argument. We all agree that you can change defaults. We're discussing what the default should be.
    - technomancy 16y ago
      The default should be what makes sense in a development environment, since rubygems is a development tool. The fact that you can use it to perform deployments as well is interesting, but doesn't concern this question. Generating both HTML and console documentation is suspect, but generating no documentation at all is much worse.

nestlequ1k 16y ago

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 16y ago
> 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 16y ago
  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 16y ago
    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.