Ruby is overwhelmingly used by developers. I understand that there are a few projects that are so popular and useful that end-users and admins might want to install them without actively developing for them. But the decision to optimize Ruby for that use case, instead of for its overwhelmingly more common use case as "developer tool", just - seems - wrong.

I don't "blame" anyone. I think Debian is wrong about Ruby.

But is that a coincidence? Python is widely used by end users -- a large portion of the Ubuntu apps are written in Python. Ruby is widely used by end users via the web (zillions of twitter users, for example), but it is not widely used for desktop apps, even though it would be a good language for them.

It wasn't Debian's place to decide that maybe Ruby should work more like Python. Packaging, by the way, is a longstanding sore point with Python developers; RubyGems is one of the few clear wins Ruby had over Python.

Really? I haven't used RubyGems, but one of my favourite things about Python packaging is that I can take a proper Python distutils-based package, and in about thirty seconds create a usable RedHat package that my sysadmin colleagues can safely and easily deploy to our production systems, alongside all the other updates they manage.

I believe various Debian packaging "helper" scripts (like Joey Hess' "debhelper") have built-in support for Python distutils packages too.

Python's index is the equivalent of rubygems.org. "pip" / "easy_install" is the equivalent of the "gem" command. "virtualenv" is the equivalent of "rvm" (more or less, I prefer virtualenv), a gem in Python's world is a package containing a "distutils" specification.

The difference: python's index is more comprehensive and CPAN still beats both :)

And look where Python is on the various distributions. Behind. Constantly behind. The day a distro decides to use Ruby for system level stuff like they used python is the day that Ruby on that distro is DoA.

Of course it's behind, and that's what end users want. Bleeding edge is called that for a reason.

Python on Debian works fine. There are a whole bunch of apps written in old versions of Python that just work, and you never have to fiddle with dependencies, and you never break them.

If you want to develop in Python, you install virtualenv and you get a bleeding edge setup exactly like you want it, and it doesn't break your working apps.

I'm not talking about local development. I'm talking about getting the running code on the server and deployed.

Want to run X ruby gem or Y python module in your codebase? Better hope it works with the antiquated version of python or ruby on the OS.

So don't do that, then.

The OS-packaged Python version is designed to support the OS-packaged Python applications. No more, no less. The whole point of having a software distribution is that it's curated such that it all works together. Your code? Not curated, so no guarantees. Module Y? Maybe curated, maybe not.

Getting "running code on the server" is an edge case, not the primary goal.

You say that as if that's a bad point: what's the point of being always on the bleeding edge for the end user ? What do you think is the work of a linux distribution (or any packager, really). I am quite proeficient in python (which has basically the same issue), and certainly can compile it by myself - but this takes time, knowledge, and is detrimental to the platform in the end if that's required. There is no hard issue that I cannot solve by myself, but OTOH, as soon as I want to share things with other people, this is nightmarish because of versions issues, incompatibilities, etc...

Lots of people use python but are not developers at core, and having constantly changing things every few months is horrible. Imagine what would happen if everybody was working the same way: gcc in debian would be optimized for gcc developers, so you are always on the bleeding edge, and if your program crashes because gcc had a bug or temporary incompatibiliy, no biggie, right ? Same for kernel, etc...

The kernel is actually a good example on how to do things: the kernel itself changes quickly, but distros do the work of stabilizing things.

I agree wholeheartedly. I develop in ruby and ocaml on ubuntu, which both suffer this problem (I assume all languages do). As a user, I have no tolerance for dealing with dependency hell for things like a desktop pdf viewer or rss reader, and a decent gui frontend to APT literally provides a one-click solution to installing an application and all it's required dependencies. As a developer, I gave up on using APT as part of my development process long ago - I manage my own library of sources and binaries. It's just too painful to synchronize a development environment with the debian/ubuntu repositories that are being updated on their own schedule. From personal experience, I can say the worst case is having your development environment break b/c you updated your email client, which is easy to do if you use APT to manage your binaries, regardless of the languages involved.