[katello-devel] When to do bundle install

[Justin Sherrill]

On 08/03/2011 02:23 AM, Mike McCune wrote:
> On 08/02/2011 09:33 AM, Justin Sherrill wrote:
>> On 08/02/2011 11:46 AM, Lukas Zapletal wrote:
>>> On 08/02/2011 07:46 AM, Mike McCune wrote:
>>>> I started down this path today and did some more importing of RPMs 
>>>> from
>>>> F15 into our internal kalpana-gems git repo.
>>>
>>> Cool.
>>>
>>> I think I found the way how to effectively run bundle install from our
>>> spec file:
>>>
>>> 1) Add all rubygem Requires also as BuildRequires
>>> 2) Delete .bundle/config and Gemfile.lock
>>> 3) Delete group :test, :development section from our Gemfile (*)
>>> 4) Run bundle install --local --without=test,development in the %build
>>>
>>> (*) - This is needed because (from the bundle-install man page):
>>>
>>> By default, bundle install will install all gems in all groups in your
>>> Gemfile(5), except those declared for a different platform.
>>>
>>> However, you can explicitly tell bundler to skip installing certain
>>> groups with the --without option. This option takes a space-separated
>>> list of groups.
>>>
>>> While the --without option will skip installing the gems in the
>>> specified groups, it will still download those gems and use them to
>>> resolve the dependencies of every gem in your Gemfile(5).
>>>
>>> This is so that installing a different set of groups on another
>>> machine (such as a production server) will not change the gems and
>>> versions that you have already developed and tested against.
>>>
>>> Bundler offers a rock-solid guarantee that the third-party code you
>>> are running in development and testing is also the third-party code
>>> you are running in production. You can choose to exclude some of that
>>> code in different environments, but you will never be caught
>>> flat-footed by different versions of third-party code being used in
>>> different environments.
>>>
>>> http://gembundler.com/man/bundle-install.1.html
>>>
>> I'm confused what this buys us?  Just because a gem is listed in
>> Gemfile.lock doesn't mean that rails will expect it to be there when it
>> starts?
>>
>>   From my experience it works like this:
>>
>> 1) bundler looks at Gemfile to determine what gems to load
>
> I thought it was:
>
> 1) bundler looks at Gemfile to look at top level gems to load and 
> builds a dep tree underneath
>
> 2) bundler looks at Gemfile.lock to match the revs of the versions it 
> is attempting to load
>
>> 2) bundler looks at Gemfile.lock to determine what versions of what gems
>> to load.
>>
>> I'm not sure what this will improve over the current setup.
>
> A) It could conceivably remove our requirement to even maintain a 
> remote gem repository for our gems.  We could rely completely on RPMs 
> and even bundle the dev gems into one RPM for dev use.

We could do this now without a problem couldn't we ?

>
> B) It will let us declare our versions at the RPM level and catch 
> errors during the build of the katello RPM vs waiting for random 
> runtime errors in CI or user reports.

I guess I'm ok with this I'm just not sure it will completely fix the 
issues at hand and might make them harder to find.  I could be wrong 
though and only time will tell! :)

-Justin

>
> Perhaps those aren't good enough reasons to make these changes but we 
> want to catch errors earlier and also make this whole rel-eng process 
> easier to wrangle.  Right now it is a PITA.
>
> Mike