4 ms·

> 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

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

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