Ruby 1.8.7 retired
ruby-lang.org
ruby-lang.org
Seriously I thought ruby was supposed to be a beacon of simplicity? Someone please tell me there's a light at the end of this tunnel.
Edit: Some folks have mentioned getting the RVM. I think I was unclear when I just said I've been fighting with ruby versions - I meant that all of this was done with RVM/gems/bundle/etc, but it's still been a p.i.t.a.
But if you are actually trying to build something to use long term - as crappy as it is to hear it now, it is not a great idea to use the system version of ruby. since it is likely as you get into ruby that you will have multiple projects which amy or may not require different subversions of ruby, you should always use rvm. it allows you to install multiple versions of ruby side by side.
also, check out https://github.com/tokaido/tokaidoapp
rvm instal ruby-1-9-3-p429
rbenv setup guide: https://gist.github.com/jasoncodes/1223731
If you're using Homebrew, you can install rbenv, ruby-build, and then use rbenv install to install a new Ruby version. Homebrew has its own version of Ruby, but it's the latest version and it's more maintainable to use rbenv or RVM to manage Ruby installations. It's sort of a pain, but once everything's set up, you won't have to think about it again.
You do not need a version manager to give Ruby a try. Although, it's a nice thing to have. If you decide to use one, you basically have 3 options: 1. rvm (most popular and bloated), 2. rbenv (simple), 3. chruby (even simpler).
If you can, I advise you to switch to Ruby 2.0. It's faster, got a lot of new features and it's becoming the default in the community.
Last piece of advice, do not mix up Ruby and Rails :)
It get's really interesting once you use puppet to install an RVM ruby version. Which you then use to install $GENERIC_RUBY package (ie Gitlab) via Puppet.
I don't want to talk about the mess called "Puppet"...
This is why it's not realistic to expect to use the system ruby for development: that's not what it's there for.
It's also worth noting that the version of Ruby in current Debian Stable (which is 1.9.3-p194) will in all likelihood be deprecated by ruby-core 2 years before the next Debian Stable release. Again, this is fine for Debian, because they have taken on the responsibility of keeping working the user applications which rely on the system ruby.
If you're complaining about the system ruby being so out of date that you can't develop applications on it, you're doing it wrong. The system ruby isn't for you.
It's getting better.
John Leach over at Brightbox has a ppa with up-to-date binary ruby packages: http://blog.brightbox.co.uk/posts/next-generation-ruby-packa... https://launchpad.net/~brightbox/+archive/ruby-ng-experiment...
I'd suggest giving them a go, and mirroring them inside your infrastructure if they work for you.
It's very annoying that checkinstall doesn't Just Work for recent ruby builds. If it did, I'd suggest that every time.
> It get's really interesting once you use puppet to install an RVM ruby version.
Yeah, don't do that.
> Yeah, don't do that.
Why not? Puppet-RVM (https://github.com/blt04/puppet-rvm ) works very well. And puppet is basically a system documentation. Since it's clear what's installed on the machine.
Second, it implies you've got build tools installed on your production machines. That's bad for security.
Third, I've seen RVM screw up too much to trust it. It's got far too many moving parts, and so far I haven't found anything I need which it does that isn't done better by some other simpler tool.
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.
Don't use rvm or rbenv on your production Linux boxes. Use packaged Ruby there.
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?
You'll need a compiler, anyway, once you start trying to use any number of libraries requiring compiled C extensions.
"No compilers on production!" might be true elsewhere but I can't see any reason it applies for ruby deployments.
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.
> 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.
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.
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.
Wow. Appeal to authority and ad hominem in the first line. Good start!
At least 2.0.0p195 is indeed in Mavericks.
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.
I have no problem with keeping software up-to-date but I don't want to make that a main task because some "cool" kids easily get bored and keep phasing out stuff which break production apps and/or causes security issues.
If you were responsible you went through several patchlevels of Ruby 1.8.7, you're using the latest release (to fix security issues if nothing else) and you had five years to migrate to 1.9 (which most likely meant changing nothing in your code, just testing it).
If you were not responsible and you're running on something different to the latest patchlevel version then you're already running on faulty/unsecure software. Killing support upstream (again, after five years!) is not likely to change whatever you were [not] doing.
PS: Please don't refer to people like the ruby-core team as "cool kids who easily get bored". We all have our biases but name-calling doesn't add anything useful to discussions.
Given that you were at the project right from the start and allowed to spend time necessary. It's funny to hear people moan on the one hand about corporate that use Java EE or even Cobol but on the other hand refuse to accept that in order for their software to be usable, it needs to be stable in some senses.
[0] Or maybe not. Your non-core [2] apps that run on 1.8.7 will still work tomorrow. Most of these applications are internal too so the risk is even less.
[1] There's almost always a 3rd party vendor who'll take advantage of a situations like this. They will make it your life easier and they'll charge you accordingly. See http://railslts.com/ for another example.
[2] If the applications that are putting the food on your table are running in an environment where no one thinks about this kind of stuff, then maybe it's time to take the wheel and start educating your team on why this is important.
[1], [2] After all management does such decisions. I have warned people face-to-face, via E-Mail, through all possible channels. So if things go wild, it's their problem, not mine.
Phasing out old version of the underlying language isn't uncommon. For example, Oracle doesn't even support Java 6 anymore, which was released in 2007.
Which Python exactly? 2.6? 2.7? 3.3? That a Python user of all people would whine about lack of stability and consistency is extremely funny.