sukria.net

Hey planet, it’s been a very long time since I took my e-pen to write something down here, my work is taking pretty much all my time nowdays. Anyway, it seems that there is sort of a polemic rising here and there about RubyGems and its packaging philosophy.

I’d like to take that opportunity to contribute to the debate with the experience I had at Yoolink. Yes, we provide Ruby on Rails applications and are defacto dealing (or trying to) with Ruby and its gems.

Wouter enlightened the main reason why it’s such a mess to put into production a Rails app and to maintain it : the Ruby on Rails ecosystem is unstable. If you start writing your app, there are very big chances that when it gets mature for production mode, one or more of the Ruby libs you depend on will have a new version. And sadly, chances are there too that one of those libs will provide an API change.

This can happen in a lot of places in a Rails app, because of its modular structure: plugins, gems or even Rails’ core upgrades (try to upgrade a real-working Rails app from 1.x to 2.x if you like tricky games).

I agree with Joss when he said that Debian packages and Ruby gems are not designed for the same purpose, the latter are for a developer ecosystem and the first suitable for long-working production ecosystems.

That’s why setting up a complex Rails app in production is a nightmare : no Debian packages for all your Ruby needs on the first hand and API-unstable and hard-to-upgrade gems on the other hand.

At Yoolink, the only working way we’ve found to maintain in production our Rails apps is to freeze pretty much every Ruby-thing we can. Our production servers are then Rails/Ruby free (nothing installed system-wide) and the apps provides all their Ruby dependencies in their vendor/ directory. You can’t do that for native gems but that works for 90% of a random Rails app’s dependencies.

To conclude, I’d say that most of these issues come from the philosophy of the Ruby/Rails people : they don’t fear to change anything they want from one release to another, just take a look at the gettext support in Rails 2.2 and you’ll understand what I mean….

It’s like they don’t even take in mind that people are now using their stuff, in real world, with customers relying on their apps. It’s not a pet project anymore guys, if Rails want to remain the killer app it is, it will have to be someting stable and maintainable.

Debian Packaging, Rails, RubyGems

It’s been a looong time since I blogged here. Perhaps I should write more frequently so you won’t start thinking I died silently ;).

I’m not dead. It’s just that I’ve started a company a couple of months ago and that does take a lot of my time. It’s pretty exciting, - as you can imagine - we’re using Debian everywhere and the team is great. I’ll write another blog-entry about that later.

In the meanwhile, I’m on holydays for a week, and I plan to squash my TODO list:

• Backup Manager (a couple of bugs have to be fixed)
• Electricsheep (a new upstream release is available)
• My Perl modules deserve a couple of maintenance too, like Coat::Persistent

Debian, perl Debian, holydays, life, perl

I’ve uploaded a new major release of TinyMCE into sid, the package jumps from the 2.x branch to the new 3.x one.

For the record, packages that use TinyMCE should rather depend on that packge instead of shipping the sources itself.

Debian

Yes I know, it’s like a year since the last development release of Backup Manager has been published, I should be ashamed of such a huge idleness.

But actually, If you ask me, I’m not. Instead of writing long lines of haiku to apologize for being so late at releasing, here is an illustrated reason why it was so loooong.

Debian, backup-manager

Dear lazyweb, this sunday afternoon, I opened BackupManager’s Bugzilla and started squashing bugs. There was 54 bugs opened that requested a review. 15 of them are now tagged “pending” (meaning they’re closed in SVN and will be shiped with the next release).

All of the patches submited - that made sense - were applied, thanks to all the reporters for their help, by the way.

So, fear a new release soon…

Debian, backup-manager

If you’re like me and want to build the ieee80211 driver for your debian box with the last kernel available in sid (2.6.24), you’ll have to apply that patch to the sources.

As you can see, a couple of changes occured in the Kernel API and that blocks the build.

Hope that can help.

Debian, General

Sam suggested in his lat blog entry to create a team whose role would be to handle the promotional stuff. I find that idea pretty good, having a central point where to take decisions regarding how Debian should communicate with the outside world makes sense.

I totally support that idea.

Debian

At work, I was voluntold to deal with an old AIX server, and today, part of my job was to get OpenSSH up and running… Erf. How the hell could someone work with the tool “smitty”? Do they call that a package maintenance system? Do people really pay for that ?

This makes me sick, why didn’t they choose Debian? I have the strange feeling of being 10 years back in time, dealing with an old interface, user-unfriendly, terminal intolerant and anti-productive.

Sometimes, life is crual.

Debian

There is going to be a Perl event in Lyon, France during November : « The French Perl Workshop 2007 ».

I’ve submitted two talks, that have been approved today:

• Perl Console - Votre compagnon pour développer en Perl (Fr)
• Redécouvrir le Perl Objet avec Moose (Fr)

I was thinking of a talk about the Debian packaging of Perl modules. That could be interesting to enlight how Perl libraries are packaged, how one can build his own package for a random module and so on.
This would be a talk designed for Perl developers under Debian. Would be great to do that with a member of the Debian Perl Group. If you’re interested, feel free to contact me so we can coordinate our efforts.

Other talks are listed on that page.

Debian, perl

A new version of PerlConsole is available. As you can see in the changelog, lots of goodness with this release comes to you (~/.perlconsolerc rules, thanks to S. Zachariah Sprackett for his patch).

After reading the source code of Devel::REPL and learning from it (this is really a great library, congrats to mst) I decided not to orphan Perl Console. Yes, that was a possibility as Devel::REPL provides anything you need to build a console (and comes with “re.pl” which actually is a console itself). I decided not to give it up for one reason: Devel::REPL is great, and better written than Perl Console (it supports plugins and profiles and is Moose-based) but, it’s slow.

When you launch it, you have to wait a couple of seconds before the console prompts you. This is because of Moose I suppose. I know that’s not blocker as a console is a development tool, but I feel like some of PerlConsole’s users would like to have the choice between a full featured, extensible and Moose-base console that’s slow, and a light one that is basic in design and implementation.

I backported one of the most interesting plugin of Devel::REPL to PerlConsole, being the console’s lexical environement. Devel::REPL did a great thing there, using Lexical::Persistence to simulate a namespace in the console.

Feel free to give your feedback about this, I wonder if there’s still an audience for PerlConsole when Devel::REPL is in the town. I think so, maybe I’m wrong, then tell me.

Debian, perl