Stickybits

Blog Categories
Twitter Updates
    follow me on Twitter
    Currently Reading
    Powered by Squarespace
    Git Projects
    « Erlang Quick Tip: The user_default module | Main | Power CouchDB - Basic HTTP Handlers »
    Thursday
    Dec172009

    Edging your way towards Ruby 1.9.1 and Rails 3.0pre

    The Rails 3 release is expected any day now but many of you, like me, may not have the patience to wait until release to start fiddling with it. So why not take the time and do some Ruby 1.9 testing at the same time. We have all been delaying the 1.9 switch but the fact is that 1.9.1 is the current stable version of Ruby and we should all really be using it for new projects. Sure there may be some gems we may need that are not 1.9 compatible yet but that is just a perfect opportunity for you to learn the new features of the current Ruby release. I can think of no better Ruby 1.9 learning tool for you than updating that gem, that you need, to a 1.9 compatible status. Also we should always remember when we build our applications that we probably saved ourselves days and even weeks by using work that others have done and given away. The least we can do is to spend an hour fixing that bug.

    EDIT: Some people prefer installing using RVM(Ruby Version Manager). I personally am a source guy but feel free to check the comments below for the RVM install info and skipping to the Rails part.

    EDIT 2: Rails is now available as a pre-release gem and the rails installation step here is out of date.

    There are many tutorials out there on how to install Ruby 1.9 but most of them involve installing the binaries with a "*19" suffix leaving you with 2 names for ruby. One called ruby and other called ruby19. I really dislike this methods as I see multiple ways how that can be annoying. I prefer my Ruby being called ruby so I usually install it in some directory that I can easily switch to by adding or removing a directory from the path.

    So lets start by creating that installation directory. I also give my user the ownership of it. That may not be a smart idea for a production machine but as this is your local dev machine it's just handy that you never have to think about privileges when installing gems and so on:

    sudo mkdir -p /opt/ruby19
    sudo chown $USER /opt/ruby19
    

    Now lets get the latest Ruby source and install to our new Ruby directory:

    cd ~/Temp  
    curl ftp://ftp.ruby-lang.org/pub/ruby/1.9/ruby-1.9.1-p376.tar.gz | tar zx
    cd ruby-1.9.1-p376
    ./configure --prefix=/opt/ruby19 --enable-shared
    make && make install
    

    All done. Now you should have ruby 1.9 set up and all you need to do is add it's bin directory to the path with the command export PATH=/opt/ruby19/bin:$PATH and you should be set to go. For convenience I usually open up ~/.bash_profile and insert to it the line:

    alias ruby19ify="export PATH=/opt/ruby19/bin:$PATH"
    

    That way whenever I open up a new terminal it will be using the default Ruby 1.8 version. But to switch to 1.9 i just run the command ruby19ify and my terminal session will use our custom ruby version and the 1.9 gem scripts. If you wish to fully switch to the new version simply add this to the path permanently. Check your Ruby install by running the command ruby -v and you should be greeted with:

    ruby 1.9.1p376 (2009-12-07 revision 26041) [i386-darwin10.2.0]
    

    Now before we install Rails we should update RubyGems to the latest version with the command:

    gem update --system
    

    While we used the Temp directory for the Ruby source files we really want to put the Rails source to your code directory as you are going to want to update this on a regular basis. The installation is dead simple:

    cd *SomePlaceYouStoreCode*
    git clone git://github.com/rails/rails.git
    cd rails
    git submodule init
    git submodule update
    rake install
    

    Now every time you wish to update Rails(do it at least weekly) you simply cd to the source directory and perform the following commands:

    git pull git submodule update rake install

    And you should be set. Check that you have Rails 3 with the command rails -v, install your gems such as sqlite3, and start hacking away at rails. If you either successfully or unsuccessfully install a gem help other by reporting it at http://isitruby19.com/ as needed. If it fails then check the source code and see if you can't assist the community by fixing it. Do a few of those and, who knows, you might end up as a Ruby superstar like Ryan Bates or Geoffrey Grosenbach.

    Remember that there are some big changes in Rails 3 that you need to be aware of. You may for example be surprised if you open up config/environment.rb as it is all but empty now. Gems are now set up using the Gemfile file in the root and there is a new file called config/application.rb for your configuration that are not environment bound. For a great collection of Rails 3 info visit the RailsNotes site.

    And remember. Fork and Patch.

    Reader Comments (8)

    Why not use Ruby Version Manager (http://rvm.beginrescueend.com) to help with testing new rubies ? It really does a great job and has been very stable and reliable for quite some time now.

    Dec 18, 2009 at 6:43 | Unregistered CommenterKenneth Kalmer

    Because I'm not talking about testing gems really. I'm talking about moving your development to 1.9. And if you happen to hit a problem in a gem that you should fix it intead of giving up and going back to 1.8.7. I've looked at RVM and, although interesting, I find it anoying to develop with.

    Dec 18, 2009 at 11:23 | Registered CommenterJón Grétar Borgþórsson

    Hi,
    I run the command "./configure --prefix=/opt/ruby19 --enable-shared", and get the follow error:

    checking whether ELF binaries are produced... no
    checking whether OS depend dynamic link works... In file included from /usr/local/include/fuse/fuse.h:26,
    from <command line>:1:
    /usr/local/include/fuse/fuse_common.h:32:2: error: #error Please add -D_FILE_OFFSET_BITS=64 to your compile flags!
    In file included from /usr/local/include/fuse/fuse.h:857,
    from <command line>:1:
    /usr/local/include/fuse/fuse_compat.h:69:24: error: sys/statfs.h: No such file or directory
    yes

    Dec 19, 2009 at 11:15 | Unregistered Commentercnruby

    That's strange. Didn't know that Ruby linked with Fuse.

    Try installing the latest macfuse and see if that fixes the problem.

    Dec 19, 2009 at 12:53 | Registered CommenterJón Grétar Borgþórsson

    Or:

    gem install rvm
    rvm-install
    # [restart your shell]
    rvm install 1.9
    rvm 1.9
    ruby -v

    Dec 19, 2009 at 14:56 | Unregistered CommenterPeter Cooper

    BTW, even if you don't like RVM as such, it's still a useful install process. You can symlink its 1.9 build (or JRuby, or whatever you want) to wherever you like, so you don't necessarily have to "use" rvm beyond the install point :-)

    Dec 19, 2009 at 14:57 | Unregistered CommenterPeter Cooper

    I think the way you install 1.9 isn't that big of a deal. Some may like using rvm and that's fine. I'm simply used to doing the source way. It's similar number of commands really but I just prefer my way for some reason. I like to see what is happening and know what's being set up and how. Funny thing though is that I only feel this way about C code. :) But I changed the article to mention your comment here as some people may not share my love for config files.

    But I think we can both agree that the most important thing to do is to install 1.9, in any way you prefer, and start testing it out.

    Dec 19, 2009 at 16:09 | Registered CommenterJón Grétar Borgþórsson

    RVM... for two huge reasons Gem sets and multiple interpreter installations.

    I have a gem set for each application. I can quickly clone a gem set into another version of Ruby at will. Test my application, run specs against all versions of Ruby, etc. Not to mention Rubinius, JRuby, MacRuby, compilation.

    I'm not going to say this article is useless. People need to understand how to compile their own libraries, including all the pain points, dependency hell, etc. its experience in order to properly administer package management.

    Good article.

    Jan 21, 2010 at 5:27 | Unregistered CommentercheapRoc

    PostPost a New Comment

    Enter your information below to add a new comment.

    My response is on my own website »
    Author Email (optional):
    Author URL (optional):
    Post:
     
    Some HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>
    Fork me on GitHub