7 ms·

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 oth

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.
    - nirvdrum 16y ago
      Could you elaborate a bit please? I've read your comment a few times over and I don't quite get what you mean that it's a "development tool." I have no idea what you mean by using it "to perform deployments." To me, and everyone I did a very quick straw poll of, rubygems is a loader for gem files. If it's truly only meant to be a dev tool, what would you suggest instead for loading third party libraries into an app?
- jarin 16y ago
  "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 16y ago
    I've seen that said about Rails, but never Ruby as a whole.
    - jarin 16y ago
      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.
rue 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. “Production system” isn't the default. Given improved speed, you can --no-doc it on your production systems. > 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* Choosing to use external tools that behave poorly with Gems isn't without its tradeoffs, nor germane to this.

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.
  - nirvdrum 16y ago
    Could you elaborate a bit please? I've read your comment a few times over and I don't quite get what you mean that it's a "development tool." I have no idea what you mean by using it "to perform deployments." To me, and everyone I did a very quick straw poll of, rubygems is a loader for gem files. If it's truly only meant to be a dev tool, what would you suggest instead for loading third party libraries into an app?
jarin 16y ago
"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 16y ago
  I've seen that said about Rails, but never Ruby as a whole.
  - jarin 16y ago
    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.

rue 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. “Production system” isn't the default. Given improved speed, you can --no-doc it on your production systems. > 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* Choosing to use external tools that behave poorly with Gems isn't without its tradeoffs, nor germane to this.