Hacker News Reader

Comment by davidroetzel | Hacker News Reader

I would love to hear more about "leverage existing package management systems".

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.

View on HN

Creating proper platform-specific packages is a mad undertaking, requiring huge amounts of manpower to setup and to maintain. We provide native Phusion Passenger packages for 5 platforms (3 Ubuntu versions, 2 Debian versions, OS X Homebrew) and it's already crazy complicated. Check out the toolchain that we spent months on building:

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.

> Creating proper platform-specific packages is a mad undertaking, requiring huge amounts of manpower to setup and to maintain.

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.

system packages and maintainers in current day are not used to support mixing multiple software with an easy separation like RVM does, they put everything in one prefix like /usr and change only application suffix, it works well with alternatives-update - but it’s static switching of ruby, what developers need is runtime switching and clear separation of libraries per language, the lack of clean separation also is bad when deploying servers that run multiple versions of given language (not limiting to ruby)

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)"

Maybe that points to one source for the packages in many distros as the wrong way to go about it? You might be better off promoting a list of packages that repo maintainers (distro or secondary) could use to supply a well known set of ruby packages for a specific target. It's not like there's a shortage of people or institutions to do this if you make it easy for them.

I don't know if creating top notch packages is too realistic, when the biggest difficulty with that is often the platform policy (e.g. insistence on separating documentation and runtime, even if it's more tightly coupled that it looks, having only one executable per package...) that is the biggest hurdle to overcome.

The fact that no platform got it right for Perl, Python nor Ruby points to a huge difficulty...

Python works pretty well with system packages.

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.

> Python works pretty well with system packages.

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.

Reply on news.ycombinator.com