It's just a different mindset. Not necessarily a _sane_ one, though...
Wouter insists that Ruby Gems are enough of an argument to keep Rails at a distance. Even though I agree with the basic claim and think that Gems are basically insane and sick, this should be taken a bit more under perspective. We are blessed. We are blessed to have Debian, such a rich OS with such a great package management system, and with superb integration between so many packages. Blessed are also the users of most Free Software based distributions, as they share the advantages of systems growing with full consciousness of their interaction’s benefits. However, integration with the rest of the world is not seamless. Most scripting languages have their own infrastructure for managing the modules/libraries/pacakges/whatevers dependencies. Perl has CPAN, PHP has PEAR, Ruby has Gems… I do see Gems as the most obnoxious of them all, but the basics are the same. The Rails crowd started being Unix-centric, but the Windows (and MacOS - they are no better, believe me, at least in this regard) world has exerted its pressure. Gems caters very well to their needs, but we do suffer the integration at the distro side. The only sane way the propietary-minded people have managed to stay clear of the well known “DLL hell” is to ship everything a given program requires bundled together - that’s the main reason for the bloat of lots of applications, and for the sloppiness of security support. Every application packager is responsible for shipping updated versions to any library it bundles in, except for the very basic core that the OS itself provides. That seems so annoyingly backwards to us that… it is unbelievable. So, yes, Rails application trees often include Rails itself. For $DEITY sake, even I have grown used to working that way, as things tend to break under your nose otherwise. My proposal (which we talked over at DebConf, but have not pushed so far) is to support simultaneous versions of Rails installed in a Debian system (of course, via different packages), more or less in the way that simultaneous versions of Ruby, PHP or Python (and, in some limited fashion, Perl - Although Perl does not suffer from this incompatible bumps. Yay for Perl!) can be installed. …And, yes, together with the pkg-ruby-extras team, I have been trying to -slowly, yes- package whatever modules we often use so they don’t have to be included in Rails applications. So far, the best way (although by far not optimal) I have found to limit this explosion of trees is to include most libraries in my Rails application trees as git submodule trees - If they are not explicitly downloaded, the systemwide libraries will be used. Yes, the “ship the whole thing as a bundle” approach is quite annoying. However, at least I must acknowledge that it works better than the approach I took with previous (mod_perl-based) webapps I wrote… As relatively few people grok mod_perl, I ended up with quite some apps which were not installed by anybody but me. Rails is obnoxious… but seems to be parsable by the humanity at large.
Comments
Dr Nic 2008-12-05 04:45:38
Barriers to helping with pkg-ruby-extras project
Its great that there is already the pkg-ruby-extras project. I only saw it a few minutes ago.
The page on “things to do to make your gem ready for debian packaging” page (http://pkg-ruby-extras.alioth.debian.org/upstream-devs.html) was very educational. I’m not sure how to create the man page it suggests, nor where it goes, but the rest was useful. I guess newgem will need to start generating the setup.rb file again (it was recently removed as there didn’t seem to be a point to it).
My instinct is to want to help with this project, though there are some immediate barriers to entry that testing the patience of my apathy. The project is hosted on svn. The mailing list is an old school mailman server (http://lists.alioth.debian.org/mailman/listinfo/pkg-ruby-extras-maintainers/). There seems to be no list of “who to contact” on the main website, rather on http://alioth.debian.org/projects/pkg-ruby-extras/ This is only annoying because I failed the basic Internet 1.0 test of “create an account” (I can’t login after verification).
I don’t like to complain, I just like to help. I shouldn’t complain, so I am sorry.
What I’d like to do if someone can help get me started:
- a “can this gem be converted to a debian bundle” test script to be run against all existing gems and all future gems
- a cron job to automatically convert all passing gems into bundles (if their dependencies were successfully converted) except those that require special love (those with known external dependencies, I guess).
- move the project to github, the conversations to google groups, etc. These are the modern tools of OSS communities afaik.
Sorry to use your blog post for these comments. Hopefully you/someone can help me help sort out this “gems are so evil” problem that sysadmin people believe. That would be nice.
Guest Ghost 2008-12-06 05:08:02
Simple solution
There is simple solution to your problem.
If Debian community does not need Ruby, Rails or gems, then don’t prodivide them.
If gems are the most obnoxious thing you know, then don’t provide them.
If it hurts to do something, then don’t do it.
To my understanding, this is free world and you are welcome to ignore what ever you want.
And it is obnoxious of you Debian people to require rest of the world to comply your standards – until you become a monopoly.
gwolf 2008-12-08 21:06:04
The thing is…
We do need Ruby. And we do want Ruby to be packagable, deployable and usable. And we (at least, some of us - At least, me) think that the Gems, although have some seemingly good aspects which bring comfort for many, are more a liability than an aid in many ways - i.e. having support for multiple versions of the same gem is just begging for an error to be present in one but not in the other, you depending on a buggy version, and an author insisting on you updating to the newer one… Gems lower the overall quality of your system. Of course, they are more than right for some needs. But not for all. If you have a coherent, consistent OS with a rich package management architecture, Gems are not that good.
gwolf 2008-12-09 07:58:56
Replied by mail…
But still - I hope this comment can spark some nice cooperation. I have re-posted this comment on the pertinent list (you don’t have to be subscribed to participate, although it’s IMHO best if you subscribe). The thread starts at http://lists.alioth.debian.org/pipermail/pkg-ruby-extras-maintainers/2008-December/003273.html
gwolf 2008-12-09 10:57:52
I do get part of your points…
Some of your points, yes, are quite true. In my case, I have been pushing towards supporting simultaneous versions of Rails in Debian, and being able to see Rails as most C-based libraries, which offer different SONAMES when API/ABI changes. I do have several systems in production, some with Rails 1.x, some with 2.x. However, the problem goes a bit further when you take just any random library. My guess is that in traditional (i.e. non-scripting) languages, people were way more careful when modifying the behaviour of their libraries, as the cost associated with relinking/recompiling/rewhatever was higher. The situation you describe, a library having a bug fix in a specific version, but having said version break older code, is not that common. However, that’s the reason we in Debian strive to support the notion of a stable releases, even if the authors themselves don’t want to support older releases - We often backport fixes to older versions, so you don’t have to jeopardize your system’s reliability, so you can keep running with known-good code, having no bleeding edges in production. And then, provide an ample time window for people to plan, test and perform their upgrades when a new system release comes along. But, no, my main gripe is not about allowing many simultaneous versions. My gripe here is rather at looking only at your own needs. Most users won’t care what language or framework your application was written in, they just want it to easily be installed and work. And that’s where a higher level integration comes along. So, yes, if you are a developer, probably the easiest way out for you is to use the gems you want and all. But when you decide to free your application and make it available for just anybody, try to play nice together with integrators. Try to depend the least possible on specific features for given versions. Try to avoid the bleeding edge. Try to avoid switching recommended infrastructures on a whim (i.e. the infamous fcgi->scgi->mongrel->passenger->whatnow).
Jens Kraemer 2008-12-09 09:56:49
What exactly is wrong with gems?
Hi!
Before I started doing Rails I’ve built several webapps with Perl, and I must say that being able to have different versions of the same gem installed at the same time is the best invention since, ehm, sliced bread :)
I still remember the nightmares of having to do a bug fix in some old application we didn’t touch in a year or so which simply wouldn’t run with recent versions of i.e. catalyst and friends because they’ve changed that much since then. If cpan supported proper versioning and parallel installation of different versions it could have been so easy…
Of course we could have avoided this by simply not using CPAN in the first place, but to be honest - while Debian is my OS of choice on the server side, I don’t tend to develop my apps using versions of ruby libraries and frameworks that are several years old just because these are the ones available in Debian stable.
Maybe it’s just me but I don’t see the problem with doing ‘gem install’ on the server. I also don’t get your point about bundling your Rails and required gems with every application - by default the Rails version a given project requires is specified in config/environment.rb and will be used automatically if installed as a gem, so all you have to do on the server is “gem install rails –version=’your version number here’” and you’re ready to go. Recent Rails even allows for automatic installation of any other required gems via a simple rake task. Deploying your app and making sure all it’s dependencies are met can’t get much easier. Plus you can deploy it on any non-Debian systems without problems if you need to.
To me, the feature you dislike most about rubygems (that is, its support for parallel installation of multiple versions) seems like the solution to all your problems. I for my part don’t bundle anything with my Rails applications that is available as a gem. And yes, I deploy to Debian systems most of the time.
So, why don’t you just use the power of Rubygems instead of complaining about how it does things different from Debian?
Just out of curiosity - how would you solve the problem of having to work on several applications, some old, some new, at the same time, on the same machine, without the ability to have multiple versions of Rails and other dependencies installed? Or do you really develop your webapps for a specific Debian release, and stick to that and its bundled Ruby library versions?
Jens Kraemer 2008-12-09 10:09:16
modern tools of OSS communities?
About the mailman vs. googlegroups thing - I really don’t get how google groups should be any better than mailman for managing a mailing list?
In general I have a bad feeling when OSS projects completely rely on infrastructure given away for free by commercial entities, be it google or github or whatever. But maybe that’s just me…
Jeremiah C. Foster 2008-12-14 15:00:31
Most ruby developers are web developers
and therein lies the problem. They don’t really sense ruby’s slowness because of the built-in latency of the internet. They don’t think about cross-platform issues because their application works in all their versions of Firefox. They abstract away all the messy bits of system development and get them presented to them via Rails.
And that is good! It is really, really good. Because programming should be easy, understandable and accessible.
But someone still needs to make the internet work, still needs to make the kernel upon which the software runs, needs to create networking protocols, and someone needs to maintain all these things.
That is where debian comes in. And as soon as one tries to do that job they realize that aptitude and friends is about as good as it can get right now and if one makes one’s software work with that, life is a lot easier.