If I had a Mac I'd skip the ad-hoc Ruby environment switchers and skip straight to Vagrant.
Then one day a rare instruction set on our colocated server (so not something super standard like linode) was specified during the compilation step of ruby and (due to an extremely subtle co-bug between ruby and the compiler). It took us fucking weeks to find this hisenbug that was somehow causing workers to drop, but only during times of very high load.
Probably lost $500k worth of customers, dev time, and company moral.
Now I have a different view. Keep things as simple and as "normal" as possible. That way you can always upgrade to the next version, you don't hit weird bugs when you libraries assume that Time.now is second-accurate, instead of sub-second accurate (MRI vs Enterprise Ruby).
RVM is made for production (http://stackoverflow.com/a/6282260/384700) and it saves a lot of headaches to just go with the flow. As for mac dev, I agree that it is a waste of time compared to working out of Ubuntu, but designers like photoshop and Vagrant is non-trivial for them to set up, especially for people that work on multiple projects.
Simple and normal, to me, means "use packaged Ruby." Chasing the bleeding edge and compiling the interpreter at every release is exactly the sort of practice that introduces edge-case heisenbugs.
If you need a nonstandard compile-time option you go to work on the package source, make the change, put your custom package up in your private apt/yum repo, and leave things alone until the next security update comes down the pike.
Me, I consider hosting to be entirely fungible. I'd rather change vendors than mess about with custom packaging big chunks of the stack to work around weirdness.
Wherever I have encountered Phusion's REE I have ripped it out, with good results.
I think most people that uses rbenv or RVM in production is only compiling new versions if the specified version isn't there already.
No.
3pt14159 said that he used to use distro-packaged Ruby, but stopped because his distro used a compile-time option that didn't play well with his vendor's hardware.
3pt14159's solution was to start using rvm on production boxes.
I think that is a bad idea, and that either:
1. 3pt14159 should just pull down the package source, change the compile time option, rebuild the package, and use the mildly customized package in production.
2. 3pt14159 should not waste time working around hardware weirdness, and just switch to a vendor that doesn't have these problems.
chruby (probably also rbenv, haven't used it) is easier to understand and trivial to set up with non-interactive shells.
export PATH=$PATH:/usr/local/rvm/bin/rvm
. /usr/local/rvm/scripts/rvm
. $REPO/.rvmrc
. $(rvm jruby-$JRUBY_VERSION do rvm env --path)
cd $REPO
bundle exec torquebox deploy
source /usr/local/rvm/environments/$BUILD
Maybe rvm/rbenv is not the best solution, but some solution is needed. You can either invent one yourself, or adapt something that's already been built. We're using rvm, and while I'm not a huge fan of it and would rather switch to rbenv, I've managed to tame it so that it's not such a huge beast, using various wrappers so that non-interactive Ruby programs work start up in the correct environment.
If it's more arcane than that, it sounds like kvm or lxc is the answer.
If you really really need to run two pieces of software with differing ruby interpreters on the same machine, then your real problem is technical debt. One fix would be to update the ancient software so that it can use modern Ruby. Another fix would be to re-architect the solution so that the greater system could operate across multiple OS instances. The least attractive option would be to use packaged Ruby for the modern stuff, and a hand-compiled Ruby for the legacy stuff.
Why?
Why can't you have a stable app using Ruby 1.9 that hasn't need any updates (other than security) in three years running on the same machine that also runs another newer application which uses Ruby 2.0 and Rails 4?
To me, that's not "technical debt".
I wouldn't want to worry about dynamic library loading flags.
> hey exist to allow developers on Macbooks to sync their version of Ruby with whatever is packaged in the Linux distro or BSD variant that runs in production.
Or to allow developers who run ubuntu to develop multiple projects which need conflicting versions of the Gem and interpreters seamlessly. Also, I sometimes deploy multiple projects on same production box where the 2 might need different interpreters, and they almost always need separate gemsets. I can manage the interpreters and LOAD_PATH manually, but then I will end up creating an unholy mess which will somewhat resemble rvm.
I am curious. What are your reasons for "rvm doesn't belong in production"?
Yeah, sure, you can have multiple versions of Ruby and the Nokogiri gem on the same box. libxml2, borrowed from the GNOME project, is the C library that is doing all of the heavy lifting underneath. If the version of libxml2 on your dev machine is different than the version in prod, it doesn't much matter if you've got the same version of Ruby and the same version of Nokogiri.
Use Vagrant. You will get a complete Linux VM for each different project that will match up perfectly with whatever the prod environment looks like.
Use Vagrant to spin up Linux VMs locally so that you can have a dev environment that matches production.
I don't work in a Ruby shop anymore, but I'd look at Bundler if I was looking to manage multiple gemsets on the same installation. As I point out in the above thread, maintaining multiple gemsets on the same machine is an antipattern that points to technical debt.
Ruby 1.8 is over. EOL. You need to port everything forward or suffer the consequences.
False dichotomy. There is no technical debt. Both Ruby 1.9.3 and Ruby 2 are functional and used in production. It will take some time to totally move to 2, and when that happens, there will be applications on different release versions of 2. I don't want to wait for os packaging to use a new ruby release, and I don't want to be forced by the packaging to use a particular version(older or newer).
> I don't work in a Ruby shop anymore, but I'd look at Bundler
Um. I use Bundler along with rvm.
> maintaining multiple gemsets on the same machine is an antipattern that points to technical debt.
Having a restriction of not more than one app on one machine is as stupid as it gets.
How does rvm fix that?
Superior package management is the reason that small teams of ops people can manage huge deployments.
In the bad old days of early Linux or traditional UNIX one had to hand-build and deploy those dozens of libraries that go scrolling by when you "apt-get install libxml2". Worse, the only way to really figure out the dependency tree was a recursive operation that involved picking a library, downloading it, attempting to build it, waiting for it to fail, figuring out what other library was missing, downloading that library, attempting to build it, waiting for it to fail, figuring out what library was missing...
Inevitably, the grad student that wrote one of the libraries somewhere in this dependency soup would have moved on, and the web page at http://morlock.iscs.random.edu/~gradguy would disappear. The next step would be to fire up an ftp client and start digging around sunsite.unc.edu and some surviving yggdrasil mirror in Australia with a banner that said "PLEASE DO NOT USE THIS SERVER IF YOU ARE OUTSIDE OF AU/NZ, WE ARE PAYING $10 PER MEGABYTE ACROSS INTERNATIONAL LINKS."
Once the software was compiled you then had to subscribe to every mailing list for each piece of software and keep an eye for security notices. If the project didn't have a mailing list you had to keep an eye on the relevent USENET groups where something might get mentioned. If the project had neither you just had to visit the FTP site every so often and see if there was a new version. If the project had a changelog you could read that and hopefully make a decision as to whether it was necessary to upgrade. If it didn't have a changelog you had to diff the old source and the new source and try to figure out what the implications were.
Package management put an end to this insanity. The Linux Filesystem Standard was an important part of this, as well.
rvm turns its back on 20 years of progress and goes takes us back to ad-hoc what-the-fuckery.
A proper Linux distribution is an exercise in distributed responsibility. Instead of saddling every sysadmin in the world with the individual responsibility of making all of these decisions, expertise is allowed to accrete with the individual packagers. The operator evaluates the quality of the distribution and trusts the packagers to do the right thing.
So what do you do if the specific Ruby version you need isn't packaged?
What's that I hear? Compile from source? How exactly is that any better than RVM? Every single piece of criticism you shouted against RVM applies just as much, if not MORE, to tarball compilation.
What if the distro only provides 1.9 but you need 2.0 features?
It sure is easy to wave your hands and accuse people of being insane.
Sometimes it is the list of default gems that is different (like how fedora packages bignum as a gem), and sometimes it is the distro packaged gems that just doesn't look like the stock versions. I've seen examples of gems split into two gems, as well as gems that has had their version dependencies altered. things like that easily makes either rubygems or bundler very unhappy.
The thing about distro packaged software is that you have to trust the distro to do the right thing, and it only takes so many examples of them doing something stupid before that trust is lost.
RHEL used to be notorious for breaking their Perl 5 dists. The first rule of Perl was to compile your own the server.