[Crowbar] Can I have Gemfile.lock back?
aspiers at suse.com
Thu Dec 20 07:33:07 CST 2012
Ralf Haferkamp (rhafer at suse.de) wrote:
> 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:
> 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
- 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
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.
More information about the Crowbar