[Crowbar] Can I have Gemfile.lock back?

Adam Spiers aspiers at suse.com
Thu Dec 20 07:33:07 CST 2012


Ralf Haferkamp (rhafer at suse.de) wrote:
> Hi,
> 
> I just noticed that Gemfile.lock was removed from the barclamp-crowbar git repo
> some time ago. What is the reason behind that?
> The offending commit is:
> https://github.com/dellcloudedge/barclamp-crowbar/commit/0eb45ccb2712312b383739c713b510d17ea70f31
> 
> It mentions that Gemfile.lock is now regenerated by the chef-recipe. This makes
> RPM packaging somewhat difficult. Especially since, when installing from RPMs
> we don't intend the gems to be served locally on port 3001. Every gem will be
> packaged in its own RPM. So calling "bundle install" in that case will not
> work. And without Gemfile.lock the app does not start.

Ralf also found that bundle install --local will generate Gemfile.lock
based on the locally installed gems (assuming that they satisfy the
requirements of Gemfile).  So there are two possible directions now:
a) bring Gemfile.lock back, or b) not.

Advantages of a)

  - the whole Crowbar community converges on one set of gem versions,
    eliminating time spent resolving issues caused by different
    versions

  - Gemfile.lock doesn't have to be generated during build process

Advantages of b)

  - doesn't require packaging a new gem rpm for every change to
    Gemfile.lock (currently only a problem for SUSE)

  - lets each member of the Crowbar community decide how often they
    want to update gem versions

  - those who update more aggressively can alert others to potential
    issues

So I'm now thinking b) might be better, and in SUSE we can just do
bundle install --local at package build-time to generate Gemfile.lock.
Then if our gem rpms don't provide versions which satisfy Gemfile's
requirements, the crowbar-barclamp-crowbar package will fail to build,
which is good.

Thoughts?



More information about the Crowbar mailing list