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@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