I recently switched to Vagrant Installers. Mitchell has done a nice job of isolating the Vagrant environment. The installer and Vagrant plugins work great, and it's a win to remove the Vagrant dependency from my project Gemfile.

Ruby-based 'infrastructure' tools should consider following Vagrant's lead. I'm looking at you, Puppet.

We very much encourage people to use the package repositories we host:

http://docs.puppetlabs.com/guides/puppetlabs_package_reposit...

Are you suggesting we should drop gem support entirely andyl?

Gems are the most confusing thing to new Ruby users.

Example that most people on HN will likely get, but most people in real life will ask you why? They have a point you should pay attention to.

If you read most ruby books you'll get one of two patterns.

1. Install brew 2. Install libyaml in brew 3. Install rvm 4. Install ruby in rvm linked to libyaml 5. gem install x and if you need y... just get another gem that supports it.

One of the core problems I've seen is most people do not grasp that a 'gem' is a package. After looking over some of the gems published to Rubygems they quickly realize the quality differs and they are at their own mercy.

Now ask yourself, why would anyone who wants their product to be (useful|used) condone this?

Basically it's a slippery slope, I understand both sides of the coin and I don't know what to say shrug

I'll be perfectly honest, as a Debian user/admin, I've never really saw the point of Gems. They just seem like Yet Another NIH unnecessary package format.

This is the classic operating-system package management/programming-language library packaging dichotomy. You see the same conflict of philosophies with Perl and CPAN packages versus Red Hat / CentOS .rpms of the same package.

Sysadmins frequently seem to like the operating-system approach. Developers frequently seem to like the programming-language approach.

I think this is because most developers haven't (yet) been paged at 3 AM to discover that everything is fucked because a handful of critical servers somehow still have bugs in libraries that were already fixed. I'm a developer and I think language-specific package ghettos are a pretty crazy way to handle deployment to production. Any dependency I can't express in the same way as all the others (namely my platform's one and only package manager) is a ticking bomb.

So on the latest version of Ubuntu (12.10), if I run "apt-get install rails" I get Rails 2.3. That was originally released over 4 years ago. There have been (nearly) 4 major releases since then. How do you work around that, or do you not?

One way to work around that is to host an internal apt/yum/etc repository and put whatever you need into a package there.

A nice way to build apt repositories is to use fpm. https://github.com/jordansissel/fpm

Although for just installing rails, using rubygems is the way to go, IMHO.