My goodness, I have very little experience with Ruby and I'm currently in the process of trying to get a rails 3 app from github running on my osx system (1.8.7 default ruby version). I have spent the past several hours fighting with ruby versions and dependencies with the only glimmer of hope being successfully getting a hello world rails 4 app running.
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.
If you want to play with Ruby and not Rails specifically, may I suggest a less monstrous framework, like Sinatra [1] or Ramaze [2]. Both come in one gem and have only one dependency - Rack (web server gateway).
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 :)
If you are just trying to hack something together - don't worry. 1.8.7 has worked for a long time, and it will continue to do so for a while.
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.
You might want to be careful: in OS X Mavericks, the default version of Ruby is 2.0.0p195. If you decide to upgrade, you'll have to go through this pain all over again.
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 should install a ruby version manager. Most apps will specify the version in the project (.rvmrc or .ruby-version). If you have a ruby version manager and the required version installed, your system will switch automatically. Installing different versions of ruby is just a one liner.
I've got a theory that this is one of the reasons that system configuration/deployment aids are so popular right now. My experience has been that there's trouble with this every time I spin up a new Ruby project (particularly Rails) and/or move to a new system. It does tend to get better as you get into individual projects, though.
I found similar problems trying to get Rails running on OSX Lion. In the end I just went to using virtual machines running Ubuntu for development. I didn't bother with RVM, I just installed Ruby with apt-get and it was all really straight forward.
The whole ruby ecosystem is a nightmare for system administrators.
Ubuntu/Debian still ships with ruby 1.8.7 and 1.9.1p0 (which is evil I heard). In order to install a new ruby version one has to most likely compile it from scratch:
- Since there are no deb packages and there is no sane way to build deb packages
- Overriding system ruby has to be avoided since we manage the whole infrastructure with puppet (yes you can run it with 1.9x). Since we want to keep the ruby environment sane.
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"...
Matz said a few days ago at the European Ruby Conference that the 1.8 -> 1.9 transition was a 'once in 20 years event' and that Ruby would not break backwards compatibility this way again until a theoretical 3.0 release which wouldn't come out for a very, very long time.
I love how he apologizes for his "limited" English and then drops a line like "[Ruby] 1.8.7 was the last scion of that clan." If that's "limited", then we're all in trouble.
That's exactly why I went with Django/Python instead of RoR/Ruby.
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 "have no problem with keeping software up-to-date" then don't complain about these type of changes. As developers we either are responsible about version policies or we're not. Let's take Ruby 1.8.7 as an example:
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.
Doesn't Django/Python have its own version headaches? (Python 3 came out 5 years ago, but Django didn't officially support until February of this year)
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.
I always have respect for people using Python to make a living. But it seems that you don't use the language as your main tool (maybe as a toy). Please, do respect all other's work even if you don't use (or hate) it.
[+] [-] pvnick|12 years ago|reply
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.
[+] [-] znowi|12 years ago|reply
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 :)
[1] http://www.sinatrarb.com/ [2] http://ramaze.net/
[+] [-] cleverjake|12 years ago|reply
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
[+] [-] phaedryx|12 years ago|reply
[+] [-] vrdabomb5717|12 years ago|reply
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.
[+] [-] nahname|12 years ago|reply
rbenv setup guide: https://gist.github.com/jasoncodes/1223731
[+] [-] wwweston|12 years ago|reply
[+] [-] MattBearman|12 years ago|reply
[+] [-] KurtMueller|12 years ago|reply
[+] [-] derengel|12 years ago|reply
[+] [-] __mp|12 years ago|reply
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"...
[+] [-] regularfry|12 years ago|reply
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.
[+] [-] disbelief|12 years ago|reply
[+] [-] judofyr|12 years ago|reply
[+] [-] JoshGlazebrook|12 years ago|reply
[+] [-] charliesome|12 years ago|reply
[+] [-] lylejohnson|12 years ago|reply
[+] [-] steveklabnik|12 years ago|reply
[+] [-] mhartl|12 years ago|reply
[+] [-] IzzyMurad|12 years ago|reply
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.
[+] [-] fbuilesv|12 years ago|reply
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.
[+] [-] VeejayRampay|12 years ago|reply
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.
[+] [-] bdcravens|12 years ago|reply
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.
[+] [-] revskill|12 years ago|reply
[+] [-] jammi|12 years ago|reply