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
> 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*
Choosing to use external tools that behave poorly with Gems isn't without its tradeoffs, nor germane to this.
"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.
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.
> 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.
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.
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?
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?
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.
I've found most of the comments on just about anything from the RubyGems guys to be off-putting, degrading, and/or insulting. Not to mention just about every new release breaks my apps on me and it's always made out to be my fault (or someone else's, but never the fault of RubyGems). It is probably my least favorite aspect of using Ruby and being part of the "community."
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.
Personally, I can switch to a browser window, google for a gem, find its docs, and read them online in less time than it takes for ri to return its usually incomplete result or ask for brain-dead disambiguation. Ruby would have a better reputation if ri simply didn't exist.
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.
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.
It's shorthand for agreeing with the original idea. It saves space and allows a much quicker scanning of the comments to find people who have something unique to say.
If everyone wrote a short paragraph on their agreement with the original idea it would be very hard to find the comments where people were either dissenting or had something original to say.
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.
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.
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.
> 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.
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
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.
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.