5 ms·
RVM belongs nowhere near production. It exists so that the guys with the macbooks can sync up versions with what is happening in the Linux distro, not the reve
by alrs 15y ago
RVM belongs nowhere near production. It exists so that the guys with the macbooks can sync up versions with what is happening in the Linux distro, not the reverse.
- mytrile 15y agoYeah, I've got Mac Mini and laptop running Ubuntu, but I guess it's only for macbooks. Clever
- damoncali 15y agoWhy not?
- alrs 15y agoBecause going back to non-packaged non-vetted flavor-of-the-month code is a retrograde step back to 1993. You lose consistency, you lose the ability to reliably recreate a same environment, you lose tested and low-friction security updates, you lose dependency management, you lose the security of a crypto web-of-trust, and you lose the google-fu of being on the exact same versions of software as thousands of other people. http://qa.debian.org/popcon.php?package=ruby1.8 http://qa.debian.org/popcon.php?package=ruby1.8
- damoncali 15y agoI'll take your word for it. For me, it mostly saves me a bunch of time. Edit: Just in case I'm coming off as snarky here, I don't mean to. My projects tend to be on the simpler end, and rvm saves me a lot of time. I'm sure it's a little cowboyish for bigger projects - I was just wondering if there was something about rvm that made it universally inappropriate for production use. Double Edit: "a bunch" is probably an overstatement. rvm was a great help transitioning to 1.9.2. I'm not sure if it will provide much utility going forward.
- sanderjd 15y agoThis is kind of a classic "fast, correct - choose one" debate. If saving time is more important, perhaps you should use RVM in production, if correctness is more important, you probably shouldn't. It comes down to how expensive your mistakes are.
- epochwolf 15y agoIf you only have one server and can script most of the install process it's not a problem. When you have more than one server, rvm is not going to save you time.
- nirvdrum 15y agoI have my gripes with RVM, but this isn't one of them. I work on a project for provisioning and deploying EC2 servers. It's a capistrano plugin called rubber. In any event, the immediate benefit is we can provide a tool that lets our users set up whatever Ruby they want to use, as we shouldn't be forcing that on them. Moreover, it makes it dead simple to deploy different Rubies out to different parts of the cluster, since everything is role-based. That's far from the common use case -- most people use the same Ruby everywhere. But if you have more complex needs, RVM affords a lot.
- moe 15y agoYour arguments sound nice in theory. Yet I don't know a single ruby shop who runs with a distro-packaged ruby, even though REE is available as a .deb.
- bonzoesc 15y agoI use the Phusion-provided .debs for REE on Ubuntu.
- nona 15y agoWe do - nothing wrong with Debian stable's 1.8.7 and/or 1.9.2.
- alrs 15y agoI do this for a living, and I've used Debian-packaged Ruby wherever I've gone. I haven't experienced issues.
- regularfry 15y agoCount us in. We only use packaged ruby, be that MRI or JRuby.
- PhilT 15y agoWhy would you not use the same version you develop your code on every day for production?
- kunley 15y agoI'd tend to agree, with one exception: it's sometimes even more desirable to construct own /usr/local version of some critical packages (database, languages, crucial libs) instead of distro versions; then recreate this on your all production nodes and never upgrade it without a carefully thought reason and pre-prod test. Two main reasons for this: - sometimes the version provided by the distro doesn't have set of features which you need and careful admin can provide it for you, - sometimes distro packagers or upstream folks violate semantic versioning (incidentally or not) and upon upgrade from distro, some of your sub-features ("sub-" doesn't have to mean "not critical") break. Of course you lose the google-fu you've mentioned, but to be honest, many production environments are so distinct that there's no sane way to compare one to "typical Debian X.Y server". I personally find FreeBSD approach very convenient wrt to the issues above, because ports evolve independently from the base system; but YMMV.
- heimidal 15y agoI know very few people using the distro version of Ruby in production. Most are using either rvm (not so desirable) or a custom-compiled version (more desirable). In my experience, the version of Ruby shipping in most Linux distros and package systems is outdated or less than ideal for production use.
- alrs 15y agoApt-pinning and source packages are great ways to bring newer Ruby in to Debian stab The first thing I did after you left our common former employer was ditch all of the manually-installed REE on Ubuntu and changed to Debian stable with .debs of ruby and rubygems pinned in from testing. It was an improvement.
- sanderjd 15y agoI'm not familiar with the technique you're referring to, is there a reference you could point me to that discusses "apt-pinning" packages from testing? We recently had a "there must be a better way" moment trying to get a standardized Ruby 1.9.2 installation set up - I think what you're describing is that better way.
- kunley 15y ago+1. Many programmers who are not admins tend to install stuff according to their one-time desire and then announce it "production ready". In fact, there's something called "release management" and it's a rather different mindset. Please coders, respect your admins (and vice-versa), or learn to play both roles. Tools like rvm, while cool, are not substitute for this, because they can create an illusion that there's nothing to learn. There is.