Number 2 does sound the best, but I have had an idea that I think would be an interesting
project. It involves standing up a Fedora RubyGem server and forking bundler so that we
can tie it into yum. Whenever you install a gem package, gem actually calls yum and grabs
the gem-rpms from our server. We could have gem2rpm spit out a src rpm that we can feed to
brew (for the gems that require compilation) and all others are just noarch. That way we
can still develop in "the ruby way" but do it all with RPMS. This idea still
needs fleshing out, mind you, but I think it is worth looking at.
Back to number 2, I thought the point of lock files was to list all of the dependencies
without having to calculate them all over again? Why would you try and get rid of the
dependencies? Wouldn't your app need them? Maybe I am just being dense on a Fri.
Check out the IT.rb group:
----- Original Message -----
From: "Lukas Zapletal" <lzap+fed(a)redhat.com>
To: ruby-sig(a)lists.fedoraproject.org, katello-devel(a)redhat.com
Cc: "Jan Blazek" <jblazek(a)redhat.com>, "Justin Sherrill"
Sent: Friday, August 5, 2011 7:52:36 AM
Subject: Distributing Rails 3 apps
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
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
I am looking forward your recommendations.
Thanks and have a nice weekend
Lukas "lzap" Zapletal
ruby-sig mailing list