Week One of Ruby on Rails: Step Backwards

gistfile1.md

I am taking a step back in my Ruby on Rails journey, as it seems that my initial goals may have been a bit too ambitious.

As I said in a previous post, this is not my first foray into web applications. I've been working with Python and its associated frameworks for some time. When I was asked by a friend to work with Ruby, I thought that there would be a fair amount of similarities between Rails and Django given the structural similarities between Ruby and Python. I could not have been more wrong.

The Ruby and Python communities have taken their languages in completely different directions, and that's just fine. Ruby has no Benevolent Dictator for Life like Guido van Rossum, and 37signals has rejected any implications that their organization can be the sole deciders for Rails. That leaves a community free to evolve however it chooses to do so. There are pros and cons to this. Ruby (and consequently, Rails) has the ability to change and grow into its users' needs far more quickly than Python. That comes with its own set of growing pains, which I encountered in my first efforts in building a demo application.

Ruby makes heavy use of gems, which appear to be like more complex Python libraries. I say "more complex" because they appear to bolt onto each other far more heavily than Python libraries. If I want to make a complex application run, chances are I'll need five gems to do it... and versioning is extremely important. I was following an application template that clearly spelled out all the gems and versions I would need to build it, but hit my first snarl when one gem wasn't quite prepared for Ubuntu 12.04 as its creator had placed some dependencies on OS X. I went debugging and fiddled with the gem to redirect it to its new home in Ubuntu, only to find that my debugging had caused problems with Rails. At this point, I decided that I should probably get a firmer understanding of the core of Rails before I started messing with gems.

So, ye Rubyists, who were so helpful last time with my RSpec gaffes - how do you manage dependencies like this? Are these gem heartburns a common problem in Ruby/Rails or is this mostly due to my ineptitude with the language?

As @krosaen pointed, are you using bundler? Also, are you using ruby version manager like https://github.com/sstephenson/rbenv or https://github.com/wayneeseguin/rvm. I highly recommend using either one of them. I personally use rbenv only because its simple (and easy to understand, if you want to know how it works). And lastly, make sure you are using the latest version of Ruby (1.9.3).

Also, this tutorial http://ruby.railstutorial.org/ruby-on-rails-tutorial-book really helped me get going with Rails. And do check out http://railscasts.com. It has lots of videos explaining various gems, rails internals etc.

as @sujithrs says, use rbenv or rvm (they are like virtualenv in python) - 90% of your problems are caused by using the system ruby and using gems from ubuntu repositories.

I was following an application template that clearly spelled out all the gems and versions I would need to build it, but hit my first snarl when one gem wasn't quite prepared for Ubuntu 12.04 as its creator had placed some dependencies on OS X.

Yeah, programmers are incredibly ignorant. Even the post docs in Haskell put absolute paths in the Perl shebang used to build Haskell. Surprise, surprise when Haskell fails to build on Haiku OS, where Perl isn't installed there.

Well, this was total linkbait. If the application template you were following was so outdated it didn't discuss Bundler, you need to find a new application template. Am I really supposed to believe that Python libraries never have C modules with OS-specific behaviour? Or that their interfaces never change to the point something like bundler isn't a must? I'd rather specify my exact versions than hope whatever is installed on the system happens to have the API version I want to use.

again, as @sujithrs and @r4vi said, always use rvm .. ruby, python have a lot of dependencies that some times requires c, c++ libs that I compiled for your system, so it is really easy to mess around when u install everything in a system context.
One think that I found out when I moved from python/django to ruby on rails was that for my python project I kind of had to create a virtual box in order to have system as close as production, but in my ruby on rails environment I dont need to do so, I run everything in my local MacOS and our prod environment(ubuntu) always worked just fine.

Interesting that you've run in to OS X specific dependencies in the Rails ecosystem. I don't know anyone who deploys Rails apps to OS X in production. Xen based VPS is so incredibly popular, that pretty much everyone deploys to some kind of Linux.

Bundler and RVM (specifically, it's gemset features) are my tools of choice for managing my Ruby environment in development. For web apps, my production environments are usually virtualized, so I don't need RVM there. I use ruby-build to compile Ruby from source on servers, rather than relying on the system packages, which are always out of date and often broken. You can get almost all of RVM's gemset functionality with Bundler, but I like the utility of commands like rvm gemset empty (this command will completely wipe out any gems in the current gemset) when I'm developing. It's handy for building from zero, and feeling confident about what gems are available in the current environment.

I used to be a rails developer about 4 years ago before switching jobs... This was before RVM, Bundler, etc... Back then, you just installed ruby, whatever gems, and then you were done. Now it seems like RVM is needed to "manage the ruby environment" and then Bundler is needed to manage sets of gems. What the heck? Whatever happened to just "Install ruby, Go". No wonder people are getting upset with it. It seems ridiculous

I'm not crazy of any language or toolchain that has a deep and version specific dependency try.