Distributing Rails 3 apps

[Tyler Smart]

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. morning :)


========= 
Tyler Smart 
Check out the IT.rb group: 
https://docspace.corp.redhat.com/groups/itrb 

----- Original Message -----
From: "Lukas Zapletal" <lzap+fed at redhat.com>
To: ruby-sig at lists.fedoraproject.org, katello-devel at redhat.com
Cc: "Jan Blazek" <jblazek at redhat.com>, "Justin Sherrill" <jsherril at redhat.com>
Sent: Friday, August 5, 2011 7:52:36 AM
Subject: Distributing Rails 3 apps

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

-- 
Later,
   Lukas "lzap" Zapletal
_______________________________________________
ruby-sig mailing list
ruby-sig at lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/ruby-sig