LWN.net Logo

On the maintainability of Ruby

On the maintainability of Ruby

Posted Jan 20, 2011 14:56 UTC (Thu) by rfunk (subscriber, #4054)
Parent article: On the maintainability of Ruby

I've been both a Debian system administrator and Ruby web developer, and while I love developing in Ruby, I hate deploying it. In particular, RubyGems has a disturbing predilection for ignoring ideas like "the system owns /usr," messing with the package-based maintainability of the system. (RubyGems prefers to put its files near the ruby binary it's using, and doesn't make it clear how to change this or whether it's even possible. Then it encourages RubyGems self-upgrades.)

The usual recommendation to use RVM is great for developers to switch between Ruby versions and implementations (except when there are a lot of gems you always want in your environment). But that usual recommendation generally starts with "gem install rvm", which means you still need one working ruby and rubygems system first. RVM is also user-oriented, and (partly because of Windows vs Mac vs Debian vs RHEL vs .... issues) doesn't very well address system-wide installation. It also doesn't help the sysadmin who may have chosen a distribution in order to centralize maintenance issues in the packaging system.

These days I tend to suggest that Ruby deployments use JRuby, keeping the sysadmin on one side of the JVM and the developer on the other side.


(Log in to post comments)

On the maintainability of Ruby

Posted Jan 21, 2011 4:25 UTC (Fri) by lambda (subscriber, #40735) [Link]

I have never seen RVM instructions that include "gem install rvm". The instructions from the RVM site itself are:

To install and/or update the latest code from the github repository ( requires git ):
$ bash < <( curl http://rvm.beginrescueend.com/releases/rvm-install-head )

I think that only people who are already familiar with Ruby and RubyGems will assume that the way to install RVM is with "gem install rvm", but when you think about it, that doesn't make much sense as RVM should manage your Ruby and Gem environments, not be installed within them.

On the maintainability of Ruby

Posted Jan 21, 2011 15:31 UTC (Fri) by rfunk (subscriber, #4054) [Link]

Ah yes, everyone is eager to blindly pipe a remote script into bash.... :-/

Sorry, looks like either installation instructions have changed since I installed it, or I misremembered. I'm pretty sure the system-wide install instructions are new though.

On the maintainability of Ruby

Posted Jan 22, 2011 0:33 UTC (Sat) by lambda (subscriber, #40735) [Link]

Have you never downloaded a tarball, untarred it, and run ./configure; make; make install before? I don't really see the difference between this and that. And if you want, you can download the script, inspect it first, and then run it; there's no reason to follow the directions exactly. My point is that RVM doesn't depend on Ruby or RubyGems as it is just a collection of shell scripts to make it easier for you to manage several copies of Ruby and RubyGems.

On the maintainability of Ruby

Posted Jan 24, 2011 17:45 UTC (Mon) by docwhat (subscriber, #40373) [Link]

It changed a while ago. The gem just uses a slightly different way to do the same thing. RVM really lives outside of Ruby, so using a gem isn't really appropriate. In fact, it's confusing since it won't update your RVM installation in .rvm if the rvm gem updated.

Ciao!

On the maintainability of Ruby

Posted Jan 21, 2011 19:37 UTC (Fri) by sorpigal (subscriber, #36106) [Link]

Oh my... nothing makes my heart race like dumping a stream of bytes from a web site into an interpreter.

On the maintainability of Ruby

Posted Jan 21, 2011 11:45 UTC (Fri) by tzafrir (subscriber, #11501) [Link]

I was considering switching our Trac installation to Redmine (once we upgrade to Squeeze). But reading this story (rather: reading it earlier) made me want to stick with Trac. Which was actually slightly easier to install. Less capable. But I won't end up with unmaintained gems.

On the maintainability of Ruby

Posted Jan 22, 2011 18:35 UTC (Sat) by bronson (subscriber, #4806) [Link]

This doesn't make any sense to me. You install Ruby 1.8.7 or 1.9.2 (your choice), Redmine and it gems. You run it. You get updates. It's all good.

It's true that another Debian dev may package Ruby post-Squeeze. So what?

You realize that Python's 2.4, 2.6, 2.7, and 3.0/3.1/trunk situation is rather similar to Ruby's, right?

What's the issue that you find so frightening?

On the maintainability of Ruby

Posted Jan 24, 2011 17:48 UTC (Mon) by docwhat (subscriber, #40373) [Link]

It's true that python is in a similar boat. This is part of the reason I custom-install python a lot on my boxes. It lets me ignore problems with the packaging of needed eggs, etc.

That being said, it's a real pain to maintain. And adding Ruby, with it's brain dead way of determining where things should go, just adds to the pain. (And yes, I know how to change all that, but it's a major pain in the neck. Things like that should be configurable on a system level, not with stupid ENV variables, without manually changing rbconfig.rb).

I totally agree with the criticisms raised in the article. We ship ruby in a commercial product and it's a total pain in the a**.

Ciao!

On the maintainability of Ruby

Posted Jan 24, 2011 20:29 UTC (Mon) by bronson (subscriber, #4806) [Link]

For the record, I agree with the criticisms in the article too. I just wouldn't use them to select Trac over Redmine. It's like selecting Ford over Chevy because

And, like you, I tend to install Python, Ruby (and especially rubygems), and Eclipse from source. They just seem to just work better. True, that's a sign of breakage, but I guess it never bothered me much.

On the maintainability of Ruby

Posted Jan 25, 2011 1:53 UTC (Tue) by docwhat (subscriber, #40373) [Link]

Well, it bothered me...if only because I used to package software, etc. for TurboLinux US and have helped with lots of Debian packages. I kept looking at it but I never could figure out how to make it better.

Perl is now, mostly, under control for me because Bugzilla (for example) installs the CPAN libraries into it's installation...which is great. Ruby is starting to be better for a similar reason: Bundler.

BTW: The article forgot to mention that unlike other interpreted languages (perl, python) you can install multiple versions of the gems and request specific ones when you 'require' them. Which means that having the Distribution manage the gems is a lot less important -- You can lock them in from the application (manually, or with something like bundler).

Oh, and one more thing. RVM can be installed system-wide: http://rvm.beginrescueend.com/deployment/system-wide/

Maybe that should be packaged instead?

Ciao!

Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds