deltacloud-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jvlcek <jvl...@redhat.com>
Subject Re: Fun with Bundler vs rubygems - ideas
Date Wed, 27 Mar 2013 12:45:35 GMT
On 03/26/2013 10:18 AM, Michal Fojtik wrote:
> Hi everyone,
>
> First. Sorry for this long email :-)
>
> I started working on refactoring of how we handle gems loading in
> Deltacloud API. This is what I discover:
>
> 1. In 'server', we don't use Bundler. If you run Deltacloud using:
>
> './bin/deltacloudd'
>
> we use the old-school 'require' all over the DC server code (do a
> "grep 'require ' -r lib/"). Having this, we always use the version of
> the gem which is currently available in the system. In most cases is
> the latest version available.
>
> 2. For 'server' tests, we do use Bundler (we call the Bundler.require
> in the Rakefile). So before you run 'rake test' you need to run
> 'bundle install'. This is not true, when the user want to execute just
> one single test file (ruby tests/.../test.rb) (yeah, he can use
> 'bundle ruby ...', but srsly, how often you forget to do it ;-). In
> that case, we again trust the rubygems and use the system versions.
>
> I think what we currently have is a bit mess :-) I found that up to
> 50% of problems, users have with DC installation is handling all
> various gem dependencies and versions (tilt, sinatra, rabbit,
> openstack, etc...). Also many bugs/jiras are related to breakages
> caused by incompatible changes in upstream gems we use.
>
> So. How we can do things better? :-)
>
> *** Idea ***:
>
> Use bundler everywhere. I don't like bundler. But I think currently it
> is the only sane way how to manage gems in DC. We should check in the
> Gemfile.lock into 'server' dir, create an initialization file with
> Bundler.require(:default) and use this to require all gems we do need
> for server to operate. Also might we need to remove all "require
> 'upstream_gem'" in DC, we we load the gems just once (when starting DC).
>
> *** Problems ***:
>
> - Different drivers require different gems. Having them all loaded by
> Bundler will increase DC boot time badly and increase the memory DC
> consume.
>
> Solution:
>
> We can create a 'group' for each driver in Bundler, like:
>
> group :ec2 do
>   gem 'aws'
> end
>
> group :rhevm do
>   gem 'rbovirt', :version => '...'
> end
>
> The the 'driver' method in Deltacloud will need to be a bit smarter
> and call the "Bundler.require(driver_symbol)" when the driver is changed.
>
> - We need to make sure that 'gem install deltacloud-core' work
> properly. Ruby gems does not play well with Gemfile.lock.
>
> Solution:
>
> We don't need 'gemspec', right? We do need gemspec **only** when we
> are building a gem (release). Can we generate 'gemspec' from what we
> have in Gemfile.lock before release? In that case we will make sure
> all gems we require have the correct versions (the one we tested on).
>
> -------
>
> I think having all gems managed by Bundler and loaded on one place
> (initializer) will make managing gems we use easier, where we can
> track what exact version we are currently supporting and we can avoid
> the issues similar to 'tilt' or 'sinatra'.
>
> There is a good article about clarification how to use gemspec vs
> Gemfile:
>
> http://yehudakatz.com/2010/12/16/clarifying-the-roles-of-the-gemspec-and-gemfile/
>
>
> "When developing a gem, do not check your Gemfile.lock into version
> control"
>
> vs.
>
> "When developing an app, check in your Gemfile.lock"
>
> In our case, we develop an app, right? The 'gem' we produce is just a
> distribution of this app.
>
>
> What you think? Do you have a better idea?
>
>   -- Michal
>

Michal,

+1

I read over the article you sited above and did a little more research and I
fully agree with this approach.

Joe

Mime
View raw message