Yup it's a shame an operating system released as early as this year (mountain lion) came with 1.8.7 because it will be around for quite a while. We recently had to make the difficult decision to continue support of it in a new release because of CentOS, Mountain Lion etc...
You are right, I'm pretty sure everyone who is a professional programmer uses homebrew, it's amazing.
However, coding to 1.8.7 lets those who aren't hardcore rubyists currently enjoy a gem they may otherwise not be able to without having to deal with or even know about rvm or rbenv.
There's gentoo/alt and fink which predates DarwinPorts. I'm sure there is even a pkgsrc user out there. I've occasionally used this one called make. It's sort of a meta language to homebeer. In fact it comes in two flavors pmake and gmake. =P
Please don't let that tempt you to use system Ruby. You should always build your own, especially on a system like OS X.
System Ruby is not there for you, it's there for the system to make use of (and yes, OS X does ship with quite a few Ruby scripts and a couple of Rails applications). Apple makes no guarantees of keeping this Ruby up to date.
I don't know what "vanilla" OSX ships with, but I've seen references to Rails pop up in logs in Console.app for my OSX Server when I was screwing with replacing their Postgres db with my own.
Er, why not? rvm was originally made for production use!
I've used rvm in production for major sites for years with no problems whatsoever, in fact I believe it is best practise. Do you have any reasons for your preference for packaged ruby?
> Sounds like an awful lot of work for no good reason I can think of.
Perfectly reproducible deploys and shutting down attack vectors are both very good reasons.
> You'll need a compiler, anyway, once you start trying to use any number of libraries requiring compiled C extensions.
Only if you're doing `gem install` in production. Guess what? That's not a particularly good idea either.
> "No compilers on production!" might be true elsewhere but I can't see any reason it applies for ruby deployments.
Ruby isn't special, or magic. It doesn't get a free pass "just because." If you've got reasons it should be exempt from the best practices that have been learnt elsewhere, let's hear them.
In the real world, we don't have unlimited time, so we have to try to balance effort required versus the outcomes we desire in order to get the best "bang for buck" out of our time. Your suggestions are incompatible with this imperative.
> Perfectly reproducible deploys and shutting down attack vectors are both very good reasons.
No they're not. Firstly, I already have good enough deploys. Secondly, the attack vector you're talking about - having a compiler installed (!) - is almost not worth mentioning and certainly does not justify the huge extra effort. We're running a business here.
> Only if you're doing `gem install` in production. Guess what? That's not a particularly good idea either.
Says you, and pretty much only you. Anything else is a massive inconvenience. Everyone does this. It may not be "perfect" but again, we are running businesses here.
> If you've got reasons it should be exempt from the best practices that have been learnt elsewhere
No, it doesn't work like that. "Best practice" does not mean a blind adherence to some decade-old set of irrelevant rules ahead of all practical operational priorities. What the ruby community has is a practical balance - workable, efficient, fast. What you suggest rings of a disconnected IT department with no incentive to make life easy for those trying to iterate fast. It smacks of ass-covering and excuses; I know it well.
You've not made any points I find compelling in the least. Anyway, I don't wish to argue about it, I simply wish to point out, to any others reading this, that your opinion on best practise for ruby deployments is controversial, to say the least.
Anyway, I doubt you've actually done any deployments at all in accordance with the ridiculous "best practise" you've outlined. I doubt anyone has. I, on the other hand, have had great success with my approach, as have countless others. As usual, the armchair quarterback has any number of wise-sounding criticisms, but is not actually in the game.
> Secondly, the attack vector you're talking about - having a compiler installed (!) - is almost not worth mentioning
I would mention "reducing the attack surface" and "privilege escalation", but you've already decided you know best on that front. Given the choice between "running a business" and "running a business securely"... well, you're happy with where you are on that spectrum, clearly.
>> If you've got reasons it should be exempt from the best practices that have been learnt elsewhere
> No, it doesn't work like that.
I'm afraid it does. Ruby may have a "practical balance", as you put it, but unless you can demonstrate, in specific, why it's better than established practice, the best practice stays. Otherwise you can't possibly understand the trade-off you're making. Blind adherence has no place here, in either direction.
I know Ruby has shiny tools for doing this stuff, but you're trading getting it done right for getting it done now when you don't actually know how much work doing it right would take. I can tell, because you seem to think ("huge extra effort"? Seriously?) packaging is hard.
> Everyone does this.
The Ruby ecosystem is the one claiming exceptionalism here, it's down to Rubyists to demonstrate why it's better, for instance, to gem install directly to production rather than build packages, and why it's worth risking rubygem's failure modes in addition to those which might affect the packaging system.
I get that it's comforting to travel in a herd. It's valuable to stop and question where that herd is going, and ask why the grass under your feet isn't better trampled.
> your opinion on best practise for ruby deployments is controversial, to say the least.
As an opinion on deployments in general, it really isn't. Now, tell me again why ruby deployments are special?
> As usual, the armchair quarterback has any number of wise-sounding criticisms, but is not actually in the game.
Heh. Cute. Wrong, but still cute :-) We can, and do, push out several ruby app deployments a day via apt-get, when we want to. Nothing stops us from iterating fast. You can have your cake and eat it too.
Sorry. I do not believe you deploy ruby apps of any significance. Your opinions are way out of alignment with the rest of the community. You're trying to paint yourself as some kind of "voice of sanity" security-wise but it is unavailing IMO.
Convenience vs security is always a tradeoff. You advocate a total lack of convenience, for a minimal, at best, gain in security (any issues are likely to be at a far higher level). I find your arguments unconvincing, to say the least, and I would decline to implement your suggestions at the 4 or so companies my opinions hold sway.
> it's down to Rubyists to demonstrate why it's better, for instance, to gem install directly to production rather than build packages
Great, an easy one. Ruby has its own packaging system and uses bundler to determine dependencies. Using this system I can install the dependencies - which may include complex custom compilations against local libraries - immediately and conveniently. I can update it any time I want.
You can't. You have some crazy manual system of packaging these compiled libraries then distributing them via some private repo. For what? You gain nothing. Now all deployments are some house of cards game of trying to get the sysadmin to package up the right X when you need it. Instead of the devs being able to deploy directly. Why would you even bother?
> I get that it's comforting to travel in a herd.
Stop trying to paint yourself as the sole voice of reason in an insane world. In this case, the herd is doing the right thing.
> We can, and do, push out several ruby app deployments a day via apt-get, when we want to
Bullshit. Sorry, but I don't believe a word you say. You have never deployed apps for a company who cares about speed and efficiency, like a startup. If you had, you wouldn't hold these ridiculous beliefs.
> Sorry. I do not believe you deploy ruby apps of any significance. Your opinions are way out of alignment with the rest of the community. You're trying to paint yourself as some kind of "voice of sanity" security-wise but it is unavailing IMO.
Wow. Appeal to authority and ad hominem in the first line. Good start!
I agree, RVM is a fantastic tool and a god send. Tremendous job by the creator. I just always felt that it was 'odd' to have to install N version of Ruby just to work on a particular project.
RVM is a very impressive collection of monstrous hacks jammed into a kitchen-sink tool to achieve a set of ends that can be better met in other ways. It's worth learning enough about how the Ruby environment fits together to figure out how. It's great to get learners off the ground (assuming it works first time), but if you're doing ruby seriously then I reckon part of your education should be how to get off it as soon as possible.
