Packaging guidelines - Bundler

[Mo Morsi]

On 01/03/2012 01:18 PM, Vít Ondruch wrote:
> Dne 3.1.2012 18:40, Michael Stahnke napsal(a):
>>
>>
>> On Tue, Jan 3, 2012 at 7:21 AM, Vít Ondruch <vondruch at redhat.com 
>> <mailto:vondruch at redhat.com>> wrote:
>>
>>     Hi everybody,
>>
>>     I am wondering if we should mention Bundler in Ruby's packaging
>>     guidelines and what should be recommendations? Or should we leave
>>     it in gray area of guidelines?
>>

The root issue isn't using bundler per-se, rather the gem dependencies 
listed in the rpm spec, gem spec, and bundler's Gemfile may become out 
of sync.

So long as the guidelines has something to address this I think we'll be 
fine. Something along the lines of it is up to the package maintainer to 
ensure all the gem dependency subsystems (rpm, gem, and bundler) are 
kept in sync.

This is the same for end-users, eg it is up to them to make sure they 
are using an application that works w/ the ruby packages shipped on the 
given Fedora version.




>>
>> So, I hate  bundler, and I don't think we should allow it.  We should 
>> however, be aware of how that will hinder Fedora as a ruby 
>> development and deployment platform.
>
>
> My intention was not in a sense of "retire Bundler", definitely not. 
> However, I would like  to clarify what is our position and suggestions 
> for packagers.
>


This whole situation is tricky as the ruby-ecosystem up to this point is 
to allow the flexibility to manage / install many different version of 
packages, depending on what the developer needs.

Great for the developer, a nightmare for the administrator, and part of 
the challenge is start pushing some of these practices upstream, eg as 
gems mature and the APIs become more stable, start relying on the OS's 
package management system for the common support model.

Perhaps a hybrid solution for the time being would be to encourage 
end-users to rely on RPMs where they can while providing the ability to 
install additional dependencies via gem / bundler. Unfortunately this 
often just leads to people using gem / bundler for everything, a habit 
that's difficult to break away from.

Conveying the benefits of RPM over gem using specific examples / use 
cases might go a long way to addressing this.




> For example, something along the lines:
>
> 1) If test suite is designed to run with Bundler, please run "$ sed -i 
> -e 's|require "bundler"||' spec/spec_helper.rb" and "$ sed -i -e 
> 's|Bundler.setup||' spec/spec_helper.rb" to remove the dependency and 
> run the test suite without it.
>

This is fine, but only takes care of this one case. So long as we have 
the blurb mentioned above (eg make sure dependencies listed in rpm, gem, 
and bundler are kept in sync), everything should fall into place. After 
that we can offer suggestions such as this one to help package 
maintainers move away from bundler usage.



> 2) If Rails application uses Bundler, remove the dependency by 
> deleting the Gemfile and Gemfile.lock and the dependency 
> initialization move into some Rails app initializer (not sure if this 
> approach is feasible). Gemfile and Gemfile.lock *must not* be included 
> in package.
>

IIRC Jay Guiditta wrote something to this effect, a tool that is 
transparent to the end user that when dropped in place allows bundler 
usage to be toggled on / off. eg the system administrator and/or end 
user can configure the underlying package system to use to resolve 
dependencies without any changes to the code.

cc'ing Jay here for more thoughts. Perhaps we can pull this in and 
standardize on it in Fedora (and even push it upstream)




>
> I can imagine other variants of the second point like:
>
> 2a) Provide specific Gemfile.lock for each Fedora version. However 
> this is fragile, since update of one gem may break the application.

Well some breakage might be the case anyways as an update to a gem 
dependency may break the app irregardless if specific versions are 
listed in the Gemfile.



>
> 2b) Delete Gemfile.lock from package and run the application for the 
> first time with root privileges.

Not a fan of this, prone to end-users / admins forgetting, and thus more 
support tickets. ;-)



>
> 2c) After first execution, Gemfile.lock is created in some world 
> writable directory, probably somewhere in /var. However this would 
> need patched version of Bundler.

Also not a huge fan of this, if for no other reason world-writable = 
bad. :-(


>
>
> As you can see, there is a lot of options, neither one ideal. Question 
> is which one we should pick?
>
>
> From developer's point of view, I believe that Bundler has its 
> advantages and I support its usage (may be not for 100% but I see some 
> use-cases). The adjustments necessary for Fedora should be done by 
> packager. If they are done sensitively and in collaboration with 
> upstream, then it is ideal.
>
>


To summarize, IMO the best solution would be to:

   - include a statement in the package guidelines stating it is up to 
the package-maintainers and application end-users to make sure they keep 
their stuff in sync with the gems in the Fedora version they are 
targeting. Maintainers should update the gemspec and Gemfile / 
Gemfile.lock dependencies for each package of Fedora they are maintaining.

   - coordiante and drive a effort in the upstream communities of the 
advantages of using a single-stack / shared-support model for packages 
such as rpm/yum or dep/apt-get when possible, while allowing for cases 
like gem and bundler when not

   - use jay's tool and build others allowing the end-users / 
administrators to switch (as seemlessly as possible) between bundler and 
yum managed dependencies, using hybrid solutions where possible / necessary.


Hope this all make sense,

   -Mo


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/ruby-sig/attachments/20120104/0e487c68/attachment.html>