Distributing Rails 3 apps

[Jason Guiditta]

On Mon, Aug 8, 2011 at 12:00 PM, Chris Lalancette <clalance at redhat.com> wrote:
>
> On 08/08/11 - 11:32:47AM, Mo Morsi wrote:
> > On 08/05/2011 08:13 AM, Vít Ondruch wrote:
> > > Option 3 is my favorite.
> >
> > Since bundler serves only to manage package dependencies with gem,
> > whereas we are trying to manage them w/ rpm, I agree it makes sense to
> > decouple these bits where feasible.
> >
> > That being said, I'm wondering if this is all this strictly necessary.
> > The bundler situation for Rails and other packages already in the yum
> > repos is already taken care of.
> >
> > And as far as the upstream projects we manage, such as Katello and
> > Aeolus, we have to select a Ruby stack to work against anyways. That
> > ruby stack can be represented in the Gemfile.lock in our git repos, and
> > whenever it is time to push a release to Fedora we can patch the
> > Gemfile.lock in the rpm spec.
> >
> > An issue w/ removing bundler from the project is that the Ruby community
> > has come to expect this w/ Rails applications. While we have to deviate
> > somewhat to conform to Fedora guidelines, staying as close as we can to
> > upstream Ruby practices is the best way to making Fedora the most
> > relevant platform for Ruby development and to get our own projects
> > accepted / used by the wider Ruby community.
> >
> > Thoughts?
>
> I guess the problem that I see is that the Gemfile.lock locks you to a
> very particular version of the gem.  In some sense this is great, as it means
> that everyone is testing on the same stack, but at the same time, it makes
> it more difficult to support the application on multiple versions of Fedora
> at the same time.  When you generate the Gemfile.lock, do you generate it on
> F-15 or F-16?  What happens when you want to put it on F-17?  What happens
> if package foo on F-15 was originally 1.0.1 (when you generated Gemfile.lock),
> but is now 1.0.2 because of a security errata?
>
> Those questions are the types of things that I think Lukas was alluding to
> in his original mail.
>
> --
> Chris Lalancette
> _______________________________________________

Two thoughts.  First, interesting (maybe not directly applicable, but
related) project for managing use of bundler _optionally_:
https://github.com/mpapis/rubygems-bundler

Second, based on above, why not make this more optional?  Not sure
precisely how it would work, but thinking something like:
* application.rb currently checks for bundler if installed.  Change
this to look for an env var on whether to _use_ bundler or not, or
simply add that check so it works either way (probably better).
* If not using bundler, either put the gems in as config.gem (old
style, if even still supported), or make a little reusable wrapper
that would take the list in Gemfile (not Gemfile.lock) and load
everything up via rubygems.  The ideal situation would be to be able
to use Gemfile with or without bundler.
** Scenario 1: RPM install:
*** initscript sets the env var that says whether to use bundler to FALSE.
*** Gemfile.lock doesnt go in the rpm and is not needed for running in
this case.  It does, however, continue to live in the codebase under
source control, as it should.
** Scenario 2: Non-RPM (gem) install/development:
*** leave the use_bundler type var to its default of true
*** bundle install, using the Gemfile.lock from source control
** Profit

-j