Distributing Rails 3 apps

Vít Ondruch vondruch at redhat.com
Fri Aug 5 12:13:01 UTC 2011


Option 3 is my favorite. I am doing so in many packaged gems, which 
relays on Bundler for the test suite execution.

Second best possibility is to maintain separate Gemfile.lock for each 
Fedora version (i.e. Gemfile.lock.f14, Gemfile.lock.f15). The 
appropriate one would be chosen by

a) developer - (s)he can either rename the file or use BUNDLE_GEMFILE 
env variable
b) automatically during RPM build time - i.e. the Gemfile.lock.f14 gets 
renamed to Gemfile.lock for Fedora 14, etc.

Vit




Dne 5.8.2011 13:52, Lukas Zapletal napsal(a):
> Hello,
>
> we are currently facing issues with bundler, rails3 and RPM packages. We
> distribute our project (katello / www.katello.org) and all it's
> dependencies as RPM packages.
>
> The problem is how to distribute Gemfile.lock file. We have some
> configuration commited in our git repo. I guess the best approach is to
> have the "oldest" libraries we have in our oldest distro we support
> (currently F14).
>
> But when we build RPMs for F14 and F15 these versions has obviously
> different rubygems, so the Gemfile.lock can't work for both. Users from
> our community are constantly hitting problems like "You have [gemfile]
> version XY, but I need version YZ". And we can only recommend to run
> bundle install as a workaround.
>
> There are few approaches to solve this issue that comes to my mind I
> would like to discuss, or frankly to read better proposals from you guys.
>
> 1) Do not distribute Gemfile.lock at all.
>
> It's pretty obvious that if we wont distribute the Gemfile.lock and
> issue "bundle install --local" in the RPM %post script, it will create
> one. The problem is this generated file is not longer part of the RPM.
> It's the quickest (but dirtiest) solution.
>
> When user upgrades a dependency, he or she could get into troubles. We
> could re-generate the lock file everytime the app is restarted, but this
> sounds more like a hack to me.
>
> 2) Generate Gemfile.lock during the build step
>
> This solution is my favorite one. If we run "bundle install --local" in
> the %build step and add all required rubygems as BuildRequire, it will
> generate the correct lock file that can be distributed.
>
> The disadvantage is obvious - we need to add all the rubygems as
> BuildRequires. Isn't there any tool for generating these lock files
> without adding many dependencies?
>
> 3) Unstitch bundler from the rails3 app
>
> I am not sure if this can be done, but the idea is to get rid of the
> bundler. In our case (RPM deployment, dependencies already solved using
> yum) the bundler tool is pretty useless. I have no idea how to do it.
>
> Sent a stackoverflow.com question - no aswer yet - http://bit.ly/oL5nNF
>
> 4) What you recommend?
>
> Bundler is a great tool for development, or agile deployment
> (capistrano, git and that kind of stuff). As a yet unexperienced rubyist
> I tend to think when it gets to RPM-based deployment, it's in the way.
> We don't need it anymore, more precisely it's an obstruct.
>
> What would you recommend to do? We don't want to bother our users with
> bundler errors, we would like to get rid of it, or to distribute always
> up-to-date Gemfile.lock.
>
> I am looking forward your recommendations.
>
> Thanks and have a nice weekend
>



More information about the ruby-sig mailing list