Turn off ri and rdoc generation by default | Hacker News Reader

Turn off ri and rdoc generation by default

github.com

86 pointswlll42 comments

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.

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

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

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

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

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

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.

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

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?

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.

I also think that it's a bit excessive. Some people seem to get frothy at the mouth when they see 'dhh.'

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.

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

That's the entire point of this discussion. A large body of Rubyists think that the sensible behavior is to _not_ install the documentation.
I google far more often than I ri.

Maybe the real problem is that Ruby documentation generally sucks! :-)

At least there are tests to make up for it. ;)

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.

I hadn't heard of "gem server" until you mentioned it.

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.

The vast majority of gemrcs on github disagree with you:
http://www.google.com/search?hl=en&source=hp&biw=101...
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.

...calling people who express a valid opinion on this "propellerheads" just seems unnecessarily insulting
When did "+1" become a valid opinion?
The few people who attempted to actually discuss the patch were more than drowned out by -- well -- a bunch of propellerheads.

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.

Is this a flaw in github? It has this nice compact list of people at the top; there's no way to join it without spamming a comment?

I like launchpad's "This bug also affects me" link. Maybe github could implement something similar.

I'd say it's a sensible default that happens to be broken in this case. ;)

they just need up-votes - effectively a plus 1

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

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

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.

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.

It's a pain when you're using rvm too, you end up with a copy of the docs for every gemset.

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.

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

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

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

This isn't Reddit.

Reply on news.ycombinator.com