https://github.com/phusion/passenger_apt_automation
https://github.com/phusion/passenger_autobuilder
And this is just one software package. Imagine at least 10 Ruby interpreters and versions (all versions of MRI 1.8, 1.9 and 2.0, all versions of Rubinius, all versions of JRuby). Now multiply that by the number of popular platforms. That's at least 13 (2 supported Ubuntu LTS versions, 1 latest Ubuntu non-LTS version, 2 supported Debian versions, latest 2 OS X versions, Windows, Red Hat, Fedora, CentOS, Arch, Gentoo). You'd end up with at least 100 different packages, and you'll have to test each one of them.
That's going to cost much more than a one-off campaign of $50000.
Of course you are right, and I am well aware of this. After all, that is the reason it has not been done before.
Still, a crazy amount of effort went into creating and maintaining rvm, rbenv and the myriad of other tools we now have. I cannot help but wonder where we would stand now had all of this instead been directed towards great packaging.
> You'd end up with at least 100 different packages, and you'll have to test each one of them. That's going to cost much more than a one-off campaign of $50000.
I am not quite so pessimistic. What I am daydreaming about would involve the distributions and their package maintainers. They already ship ruby right now. The packages are just not in optimal shape and oftentimes not up to date.
But one can surely build on the foundation already laid out by the distributions and work with them to hand off some of the work.
Still, I know this would be a herculean task. And not only a technical challenge, but a social one as well.
also check the update with schedule - https://www.bountysource.com/fundraisers/489-rvm-2-0 - "2 months: Work on building packages using RVM 2 (so it deprecates itself)"
The fact that no platform got it right for Perl, Python nor Ruby points to a huge difficulty...
Few people compile Python from source in the way that is common for Ruby. People do use pip/ virtualenv, but those are more the equivalent of bundler/ RVM gemsets-- they manage libraries, not entire interpreters. It's a little confusing because virtualenv appears to have its "own" Python, but really it is a symlink to the (usually) system interpreter managed by the distro.
The major distros have representatives who are active on python-dev in working out any issues that may make integration difficult between Python and the distros.
Does it? From my limited exposure to python I remember that e.g. recent CentOs comes with python 2.6 only and installing any never version requires you to manually compile it while being extra extra careful not to touch the system python since otherwise yum dies.
Ruby works just well on that level - as long as the system ruby is fine for you, all is settled. For the rest of us that need a never/other ruby there's rvm/rbenv/chruby.
I guess many people use rvm to install ruby and I always recommend newbies to try it out for that purpose.
But recent criticisms of ruby made me wonder if that really is the right approach. Maybe it would be better to put more effort into creating top-notch packages for the major linux distros (and, say, homebrew). And to work with the distributions on the stable packages, while offering official repositories to get the latest versions.
rvm could still play a role in this scenario as a tool to switch between versions, isolate gem installations and so on, offering a unified interface that hides the platform differences of the distros.
I would certainly donate to such a cause.