[katello-devel] When to do bundle install (was: Installing on F15)

[Mike McCune]

On 08/01/2011 12:48 AM, Lukas Zapletal wrote:
> On 07/29/2011 04:23 PM, Brad Buckingham wrote:
>   >>>
>   >>  well.. I did this form the rpm.. so I assume I need to add a bug to
>   >>  the rpm to not include this file? (Gemfile.lock fyi)
>   >>
>   >>  -- bk
>   >>
>   >  +1.  Please do open a bug for this one.  Thanks!
>
> But only as a temporary workaround.
>
> We should definitely *distribute* the Gemfile.lock file. It is the main
> idea of Bundler - to lock all the gem versions to make sure everybody
> (incl. end users) are running on the correct versions. But we are not
> doing it correctly right now as we distribute the one from our git. That
> is definitely not the right way.
>
> Bundler (Rails) wont start without this file and it must be created
> using "bundle install" command. At the end of the day we should have it
> in the build section of our spec file. It will "lock" itself in the
> correct (mock) environment and users are forced to use the correct versions.
>
> We already had it there (**), but there were some issues with
> dependencies, so I had to remove it. Basically we would need to have all
> the rubygem requires also included in the buildrequires. I dont know if
> there is a spec macro or something that would automate this thing. Or we
> would need to keep Require and BuildRequire lines the same.
>
> This step would also require us to really have all the RPMs on the
> building machines physically. We are currently able to "build" RPMs on
> boxes that has just gettext rubygem and few other deps, because its all
> about making a tarball at the moment.
>
> The side-effect of this is we wont be able to build in Fedora Koji until
> we get all the rubygems into the Fedora, because the mocker needs it
> there. I think we could live with that.
>
> To finally get rid of "bundle install" issues we need to take the
> following steps:
>
> 1) Add all the required gems as BuildRequires
> 2) Install all the deps to our building machines
> 3) Add bundler install --local command to the SPEC
> 4) Distribute the generated Gemfile.lock
>
> Please note "bundle install" does not install anything if all the
> required rubygems are already installed. It will just create the lock
> file. Providing the "--local" option we disallow downloading during
> this, so error is reported if no system-wide rubygem is found.
>
> If we do this, users will be not facing these issues any more. If we hit
> dependency issues the RPM wont be created. So it's prevention.
>
> I could do more testing and find out if this is feasible. There could be
> also an option to get rid of the Bundler in production mode, but I dont
> know how to run Rails without it.
>
> (**) - e97f3229a2f95ae4841bc549b7e4515b1df2c97f

excellent plan, definitely +1 to all the above.  We can work towards 
this in the coming days.

I started down this path today and did some more importing of RPMs from 
F15 into our internal kalpana-gems git repo.  I haven't pushed or tested 
these changes just yet because I ran out of time and didn't want to 
block people.  Just a heads up that I have a pending change that includes:

commit 746c680fd0c8273757ad76aefbcfcb2e02b35b24
Author: Mike McCune <mmccune at redhat.com>
Date:   Tue May 3 13:35:19 2011 -0400

     Adding script to import from F15 -> kalapan-gems.  Also more sync 
with f15

A       gems/rack-test-0.5.7.gem
A       gems/regin-0.3.7.gem
D       gems/regin-0.3.8.gem
D       rack-test/rack-test-0.5.7.gem
D       rack-test/rack-test.spec
D       rack-test/tito.props
D       rake/rake-0.8.7.gem
D       rake/rake.spec
D       rake/tito.props
A       rpms/rubygem-rack-test-0.5.7-1.fc15.noarch.rpm
A       rpms/rubygem-rake-0.9.2-1.fc15.noarch.rpm
A       rpms/rubygem-regin-0.3.7-3.fc15.noarch.rpm


Mike
-- 
Mike McCune
mmccune AT redhat.com
Red Hat Engineering       | Portland, OR
Systems Management        | 650.254.4248