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(a)redhat.com
> <mailto:firstname.lastname@example.org>> 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
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
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
'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
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 =
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,