<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
On 01/03/2012 01:18 PM, Vít Ondruch wrote:
<blockquote cite="mid:4F034666.6090201@redhat.com" type="cite">
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
Dne 3.1.2012 18:40, Michael Stahnke napsal(a):
<blockquote
cite="mid:CA+_jt2ZGrV+2Lw2qFGx8+3pTstvWu-zCPG3q9i5_E5Ci36pR2A@mail.gmail.com"
type="cite"><br>
<br>
<div class="gmail_quote">On Tue, Jan 3, 2012 at 7:21 AM, Vít
Ondruch <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:vondruch@redhat.com">vondruch@redhat.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;"> Hi everybody,<br>
<br>
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?<br>
</blockquote>
</div>
</blockquote>
</blockquote>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
<br>
<br>
<br>
<blockquote cite="mid:4F034666.6090201@redhat.com" type="cite">
<blockquote
cite="mid:CA+_jt2ZGrV+2Lw2qFGx8+3pTstvWu-zCPG3q9i5_E5Ci36pR2A@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<div><br>
</div>
<div>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.</div>
</div>
</blockquote>
<br>
</blockquote>
<blockquote cite="mid:4F034666.6090201@redhat.com" type="cite"> <br>
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.<br>
<br>
</blockquote>
<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Conveying the benefits of RPM over gem using specific examples / use
cases might go a long way to addressing this.<br>
<br>
<br>
<br>
<br>
<blockquote cite="mid:4F034666.6090201@redhat.com" type="cite"> For
example, something along the lines:<br>
<br>
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.<br>
<br>
</blockquote>
<br>
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.<br>
<br>
<br>
<br>
<blockquote cite="mid:4F034666.6090201@redhat.com" type="cite"> 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.<br>
<br>
</blockquote>
<br>
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.<br>
<br>
cc'ing Jay here for more thoughts. Perhaps we can pull this in and
standardize on it in Fedora (and even push it upstream)<br>
<br>
<br>
<br>
<br>
<blockquote cite="mid:4F034666.6090201@redhat.com" type="cite"> <br>
I can imagine other variants of the second point like:<br>
<br>
2a) Provide specific Gemfile.lock for each Fedora version. However
this is fragile, since update of one gem may break the
application.<br>
</blockquote>
<br>
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.<br>
<br>
<br>
<br>
<blockquote cite="mid:4F034666.6090201@redhat.com" type="cite"> <br>
2b) Delete Gemfile.lock from package and run the application for
the first time with root privileges.<br>
</blockquote>
<br>
Not a fan of this, prone to end-users / admins forgetting, and thus
more support tickets. ;-)<br>
<br>
<br>
<br>
<blockquote cite="mid:4F034666.6090201@redhat.com" type="cite"> <br>
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.<br>
</blockquote>
<br>
Also not a huge fan of this, if for no other reason world-writable =
bad. :-(<br>
<br>
<br>
<blockquote cite="mid:4F034666.6090201@redhat.com" type="cite"> <br>
<br>
As you can see, there is a lot of options, neither one ideal.
Question is which one we should pick?<br>
<br>
<br>
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.<br>
<br>
<br>
</blockquote>
<br>
<br>
To summarize, IMO the best solution would be to:<br>
<br>
- 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.<br>
<br>
- 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<br>
<br>
- 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.<br>
<br>
<br>
Hope this all make sense,<br>
<br>
-Mo<br>
<br>
<br>
</body>
</html>