Frankly, I do not want to care. I want the latest stable version with security fixes. With a busy work schedule, I do not have time to maintain a stable set of Ruby modules. It's a matter of economics: you could let every user find out a stable combination of modules, and everyone will end up doing a lot of duplicate work. Or the distributor could do it, saving 95% of the users who do not have specific needs many hours of work. And as a bonus, we all get the collaborative testing and bug reporting that was done in Debian Unstable and Debian Testing.

This approach works well for many interpreters and compilers in Debian (as someone else pointed out, Python is well-integrated in Ubuntu and Debian).

I'm coming from the perspective of a ruby application developer. I've got my server, it's all set up, I type 'cap deploy' and it takes care of everything, including my dependancies. I don't need to 'figure out what works,' because my application is developed locally, I already have all of the versions worked out, because it's what I was building the software with. This situation is a happy one. Everything's good. Yes, I'm technically using two package managers, but I don't really care: it's all been abstracted away, and everything _actually works_.

If I try to do things through apt, all of the gems simply aren't there. Or older versions of things, which break because my code was written with newer ones. It's simply a non-starter.

However, from a sysadmin standpoint, where you're keeping Ruby on a system for a certain reason, the use case is totally different.

The real problem happens when people who use Ubuntu because they're new to Linux want to start with Rails, and it has to be explained that almost nothing they read will actually work properly. They're the real people who suffer out of all of this, not you and I.

I've heard this before, but I almost wonder if it's the exception that proves the rule. That is, the rule is: your OS is not likely to provide up-to-date development library packages (or interpreters for that matter) for your scripting language of choice. As a developer, you will need to get and build stuff by hand, you will need to manage a complex set of changing load paths, you will need lots of coffee and help. You will come to rely on and love tools outside of the normal distribution tool-chain.

I don't do Python, but this rule has proven to be true for me for Perl and Ruby, on systems including OSX, OpenBSD and Debian. I always end up having to get cpanm to install Perl modules, Perlbrew to install newer (or variant) Perl interpreters and ditto for Ruby, rvm and company. (I dabble in Haskell and Lua, and it's true there too so far as I can tell. But my experiences with those languages are too limited to really say.)

I think that Python is a special case, and I honestly don't know why. Maybe they've figured out something that Perl and Ruby haven't. Maybe it's because Gnome is built using Python very heavily, and Debian ships with a default Gnome desktop and so they care more about Python. Maybe the Python team at Debian is just better staffed. I don't know, but Python is the exception here.