Bundler and Public Git Sources

Thu Sep 16 17:58:00 -0700 2010

If you have a public git source in your production Gemfile, then you are doing it wrong.

Bundler rocks. It lets us point our Gemfile source at almost anything, a path, a git source and of course RubyGems.org.

But if you are using production code, and you have something like this in it:

gem "mail", :git => 'git://github.com/mikel/mail.git'

Then you are most likely doing it wrong.

Why? Well, you have no guarantee that I will keep that repository around. I (or any github user) could just deleted it tomorrow. And then your deploy is broken.

Not only that, the reason you are pointing to a git source is because there is some production critical feature that you need from the git source. Otherwise, you would just be specifying the gem version in your Gemfile.

So this is a recipe for disaster.

I recently took over a project (Rails 2.2.2) that had over 13 gems specified in the environment.rb file using the Rails 2.x style config.gem commands that were pointing to explicit gems inside of Github. My first action was to go in and Fork those gems into the client’s public git repository and depend on THOSE versions, ones that are under our control.

Of course, the next step is to go through and remove any git dependency from the Gemfile, one by one and just revert to normal gems from somewhere like RubyGems. But this has to be done incrementally and will happen over the coming weeks.

So, go through your production code, and if you are pointing at someone else’s github tree, just go in and fork it and point at your own. It is cheap insurance.

blogLater

Mikel

  1. autodiveja Says:
    Tue Nov 08 19:35:59 -0800 2011

    Very interesting point. Interesting enough I’m using similar approach with several of js libs I use with git submodules.

  2. Radoslav Stankov Says:
    Fri Sep 17 04:03:58 -0700 2010

    Very interesting point. Interesting enough I’m using similar approach with several of js libs I use with git submodules.

  3. Philippe Creux Says:
    Fri Sep 17 10:34:44 -0700 2010

    Your totally right. From worst to best I would say:

    gem “mail”, :git => ‘git://github.com/mikel/mail.git’
    gem “mail”, :git => ‘git://github.com/mikel/mail.git’, :ref => ‘5efd6s…’
    gem “mail”
    gem "mail, “2.3.4”

    Specify the version – it could save you from being forced to fix your code every time a new version of a gem is released.

    I work on a Rails 3 app and we don’t have any other choice than using git repos as the gems for Rails 3 are not released yet. For instance:
    gem ‘will_paginate’, :git => “git://github.com/mislav/will_paginate.git”, :branch => ‘rails3’

    In that case… you could fork mislav’s repo in case he deletes it. :)

  4. fds5ugh Says:
    Sun Feb 05 20:23:21 -0800 2012

    Very interesting point. Interesting enough I’m using similar approach with several of js libs I use with git submodules.why am i so tired gd hypothyroidism symptoms

Leave a Reply