Mon, 24 Nov 2008
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!
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).
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.
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.
/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.
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.
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...
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.