Rails? Stay the f* away from my system.

I knew for a long time that rails is somewhat fun to work with. The first time I read something about it, I went to check it out, and kindof liked the idea. Web development really isn't my cup of tea, so I didn't do anything with rails; but really, the idea made somewhat sense to me.

It's unfortunate that the implementation is such a piece of crap. Luckily I don't have to deal with it firsthand, but the stories I hear and read everywhere speak for themselves. I won't enumerate them all; but in case you're not familiar with them, the Debian Ruby team has a pretty clear explanation on their website. In addition to complaints by packagers, I also hear that many ruby developers recommend that you install gems inside the project you're running (or that you ship your software in such a way that it includes those libraries as part of your source). Oh, the horror.

Now, however, they've really topped it. Via Koen's blog, I found some other page that contains this:

Now, in theory, to update to the latest version of RubyGems, you just need to run

sudo gem update --system

But - depending on what version of RubyGems you have installed, running that command may lie and tell you that you have nothing to update. If you’re currently on RubyGems 1.1 or 1.2, you need to run a different set of commands to update RubyGems:

sudo gem install rubygems-update
sudo update_rubygems

Seriously. This is why we have distributions, packagers, and, really, people spending a whole shitload of time making sure everything works together nicely. This is why there is Debian, RedHat, CentOS, Mandrake, SuSE, and whatever.

Me touching rails? Not with a 10-foot pole. Not if you pay me a million, in any currency. Stay away from my system!

Ruby on Rails vs proper packaging

RoR comes from people who mostly have a MacOSX and Windows background and, at least on the latter, packaging is known to be really poor. But then again, almost everyone deploys those apps to production systems running Linux or *BSD. It's the same annoyance with PHP/PEAR though, a native half-assed "packaging" system that doesn't blend into the native one.

Shipping dependencies within the project itself isn't all that bad though, at least you mostly remain isolated from whatever updates the sysadmin aptitude's on the host. The drawback, of course, being that when it is in order to fix a security vulnerability....

Unfortunately, it's really difficult to bridge Ruby gems with dpkg/rpm packages. Not having portable APIs/tools to create packages for dpkg and RPM (and ...) based systems clearly doesn't help though :\ At least Python's setuptools has the option of creating RPMs (not exactly as good as a proper .spec file but well, not all that bad either).

Comment by Pascal Bleser (pascal.bleser@opensuse.org) Mon Nov 24 20:10:22 2008
AOL
The gems packaging nightmare was one of the reasons that I've steered clear of ruby and started looking at other things. The other was the shocking state of some of the libraries on the inside (REXML and redcloth being two)
Comment by Jon (jon+grep.be@alcopop.org) Tue Nov 25 12:47:48 2008
Troll much?

Really now. Are you seriously writing an article bashing a framework that you admit that you have never used? You thrash it based on some articles you have read on the web? And you also state that you don't do web development?

And you think I should listen to you why?? What qualifications do you have to open your mouth on the topic?

Shut the f* up.

Comment by trollcaptcha Thu Dec 4 19:30:36 2008
rails linux packages

While agree rails has it's issue how many times have I had to fight apt-get to get something properly installed, broken by a variety of outdated and incompatible dependencies? Not to mention what they consider good application structure...

/var/apache #some files /etc/apache #config shit /log/apache #logs

How is that better than being able to install apache anywhere on a system and having it be a full application package

/var/apache/all_apache_subdirectories

every time I set up or install something on linux I have to search around for various log, config, and actual files which is a nightmare.

Comment by Dan Mayer (danmayer@gmail.com) Thu Dec 4 19:33:41 2008
Not really understanding

I'm really confused. Do you have a problem with ruby gems or rails? Ruby gems is a method of distributing ruby packages on any platform. It also allows ruby apps to use different versions of packages on the same system - very useful for shared web hosting for example, where you may have sites running on different versions.

Rails the framework has nothing to with gems specifically other than it being a method of distribution.

If I've missed your point, do clarify.

Comment by Steve Thu Dec 4 19:35:03 2008
It's not Rails, it's Ruby

The problems you are describing are not problems in Rails, but problems in Ruby. They are not the same thing!

Also, I can tell you from experience that rubygems gives you less headaches then for instance apt-get. Once you get it running (which is relatively painless, the problems you describe are well documented), it just works!

You really shouldn't knock it before you try it...

Comment by Tom-Eric Gerritsen (tomeric@i76.nl) Thu Dec 4 19:51:02 2008
ruby as a second class citizen among linux distros
not that rubygems awfulness don't have anything to do with it, but ruby is sadly treated like a second class citizen among linux distros... hopefully some folks come together and make this change
Comment by anonymous Thu Dec 4 19:53:02 2008
debian packagers stay away from ruby.
Comment by me (kdflaskdal@fdafdsad.com) Thu Dec 4 20:00:06 2008
you stay away
debian packagers please stay away from rubygems. don't try to hack it with your archaic debian package system. thanks.
Comment by me Thu Dec 4 20:09:42 2008
Clear up some confusion

You seemed to be confused. The RubyGems system has nothing to do with Rails other than Rails packages exist for the gem system if you choose to install Rails that way.

Now if we assume you mean RubyGems and not Rails then maybe we can have a thoughtful discussion. The RubyGems system is certainly not perfect. That is why it is not even part of the standard Ruby distribution (although all indications are that it will be in future versions of Ruby). But it is solving two real problem that other package management systems are not addressing:

  • Easily allowing multiple versions of the same library/program to be installed. DEB, RPM, etc don't handle this well (they usually end up with some sort of mylib2 mylib3 hack).

  • Easily allow one package to be used on multiple operating system. Doing it your way I need to make a .rpm (probably several for each Redhat-based distribution), a .deb (again several for each Debian-based distibution), a .msi (for Windows and probably multiple for this also) and a .app (for Mac). And that is just hitting the main systems. That doesn't count the hundreds of systems that don't have any package manager or have some unheard of package manager.

Rubygems solves both of these problems reasonably well. Yes it doesn't integrate with the native package manager and that is unfortunate to loose the consistency. Also there are probably some things that rpm, deb, msi, etc do well that .gem is not doing as well. But as a Ruby developer I can live with that in exchange for my install instruction to be:

gem install myapp

regardless of the OS. And I only have to develop one package. Not perfect but it is better than the autoconf, multiple package hell that many other environments face. And of course there is no reason software cannot start as a gem (for people close to the ruby community) but as it's popularity increases packages can be created that are more tightly integrated into the native package manager.

Two other points:

  • As for the upgrade snafu. I've been using RubyGems for several years and only rarely have my instructions been different than rubygems upgrade --system. This was one of those time. Rare but still simple to fix.
  • As for packaging gems with a Rails project. This is a practice encouraged when your app is deployed in a shared host environment (to prevent a system upgrade from breaking your app) and for cases where you are distributing generic software. If you have control over your server or are developing in your local environment there is no reason to package a gem up with your app. Depending on the app and depending on the hosting environment will determine if this is something you need to do. And this is not something exclusive to Rails. Most projects that have vender dependencies have to decide if they should be rolled into the app or as a separate requirement. And again depending on the app and deployment environment will determine the answer to that question. There is not right or wrong answer for all environment. Each situation needs to make that evaluation.
Comment by Eric Anderson (eric@pixelwareinc.com) Thu Dec 4 20:51:39 2008
Re: Ruby on Rails vs proper packaging

I agree, RoR developers mostly work on proprietary systems and therefor don't really have an allegiance to one platform over another. This, in a way, shows how far things have come. It used to be if you wanted to develop for Windows, you used VisualStudio, if you wanted to target OS X, you had to dive into Objective-C, but Ruby has flourished, along with perl, python, etc. on these platforms.

This shows that the platform doesn't matter to a lot of developers any more - they are targeting the web, not an OS. But a good OS is still hard to do and web developers are not necessarily the most qualified to discern the details of File system implementation, compilers, and the like, since they never deal with those things.

Plus a good OS, like debian, is getting harder to do. It needs to accommodate not just the web developers slinging ruby, but the cluster people who want high availability, embedded people who want C and small tools, and those who are trying to do high performance computing.

That is why I think it is best that ruby accommodate debian and make a more generalized way of installing software. If they don't they are surely doomed to repeat a lot of fun dependency hell.

Comment by Jeremiah C. Foster Sun Dec 14 23:06:17 2008
Re: rails linux packages
The issue of files all over the system is not debian-specific but rather inherited from UNIX. The FHS is meant to solve this, and debian works harder than any one else to implement the FHS.
Comment by Jeremiah C. Foster Sun Dec 14 23:08:32 2008