Distributing Rails 3 apps

[Chris Lalancette]

On 08/08/11 - 05:23:18PM, Jason Guiditta wrote:
> 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

Yeah, this certainly seems like a reasonable way to go about it.  What we could
do there is to set the use_bundler variable to true in source control, and then
in the RPM spec file set it to false for deployment.  I like it :).

-- 
Chris Lalancette