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(a)redhat.com&gt; To: ruby-sig(a)lists.fedoraproject.org, katello-devel(a)redhat.com Cc: "Jan Blazek" <jblazek(a)redhat.com&gt;, "Justin Sherrill" <jsherril(a)redhat.com&gt; 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(a)lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig

RPMs are a must, but the question is where do we generate them? If we stand up our own rubygems server, we could have that server generate RPMS and then grab them from there whenever we do a bundle install or gem install. Or the other option of generating an rpm locally could also work. ========= Tyler Smart Check out the IT.rb group: https://docspace.corp.redhat.com/groups/itrb ----- Original Message ----- From: "Lukas Zapletal" <lzap+fed(a)redhat.com&gt; To: ruby-sig(a)lists.fedoraproject.org Sent: Friday, August 5, 2011 10:12:25 AM Subject: Re: Distributing Rails 3 apps On 08/05/2011 02:11 PM, Tyler Smart wrote: Interesting idea, but as Vita said later in the thread - RPMs are a must. Thanks for tips! -- Later, Lukas "lzap" Zapletal _______________________________________________ ruby-sig mailing list ruby-sig(a)lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig

On Fri, Aug 05, 2011 at 10:27:03AM -0400, Darryl L. Pierce wrote: Chris Lalancette and I have been talking about exactly this issue. I'm not 100% sure it's appropriate for Fedora, but I don't think there's any getting around Fedora users' needs to install parallel stacks of application code (RVM, as mind-bogglingly evil as it is, exists to serve a need -- if we could fill that need in a less evil way we would be doing the Ruby world a service, I believe). --Hugh -- == Hugh Brock, hbrock(a)redhat.com == == Engineering Manager, Cloud BU == == Aeolus Project: Manage virtual infrastructure across clouds. == == http://aeolusproject.org == "I know that you believe you understand what you think I said, but I’m not sure you realize that what you heard is not what I meant." --Robert McCloskey

Well bundler is supposed to be a way to manage parallel stacks of gems on a per-application basis. We just need to make sure that the Gemfile.lock that ships in our project releases match the rpms being shipped in Fedora. In any case, parallel stacks should be straightforward, as they are already exist in Fedora, whether it be via 'compat' packages or putting the version from the name-version-release into the name (such as with python1.9) -Mo

I agree, it's a maintenance hassle, and should be discouraged except for where strictly necessary. The Fedora Ruby community should try to converge on a single Ruby stack wherever possible (honestly I think we've been good with this so far). -Mo

We are meeting in Raleigh tomorrow at 12 to discuss solutions for solving this problem. We will put the best ideas down and present them to the Fedora community. Whichever one resonates with everyone we will start implementing. (At least the local Ruby meetup here will help to start working on it) ========= Tyler Smart Check out the IT.rb group: https://docspace.corp.redhat.com/groups/itrb ----- Original Message ----- From: "Mo Morsi" <mmorsi(a)redhat.com&gt; To: ruby-sig(a)lists.fedoraproject.org Sent: Monday, August 8, 2011 12:05:36 PM Subject: Re: Distributing Rails 3 apps I agree, it's a maintenance hassle, and should be discouraged except for where strictly necessary. The Fedora Ruby community should try to converge on a single Ruby stack wherever possible (honestly I think we've been good with this so far). -Mo _______________________________________________ ruby-sig mailing list ruby-sig(a)lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig

On Fri, Aug 05, 2011 at 04:32:04PM +0200, Vít Ondruch wrote: Ah, I wasn't aware of that. So it's possible to have rubygem-rails 2.3.11 and 3.0.0 installed on a single system? Does RPM properly handle updates to either one; i.e., 2.3.11-5 is installed and release 2.3.11-6 is made available? Or would RPM treat that as a third version of the RPM and install it? And, assuming we leveraged this, how does it handle common files between packages, such as /usr/bin/rails binary? I would think we could solve that by using an alternatives-type of solution, at least for binaries. -- Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc. Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/

On Fri, Aug 05, 2011 at 05:12:23PM +0200, Vít Ondruch wrote: Okay, so that's a hurdle to overcome. It seems the best example (the kernel package) closely matches what we want to be able to do. Yum will install a newer version without removing a previous version (up to a set number IIANM). Yeah, I'm going to bet that there will be changes that will cause problems. So what we'd want then is something like alternatives for things like the rails binary and similar. So next question is, how do you go about proposing a solution if/when one is defined? -- Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc. Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/

On Fri, Aug 05, 2011 at 01:19:24PM -0400, Tyler Smart wrote: Yes, pretty much. -- Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc. Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/

On 08/05/2011 02:13 PM, Vít Ondruch wrote: I knew there is somebody with the knowledge HOW to do it! Cool. Please point me somewhere I could read more about it. Or just some examples would be enough. I have no clue how to get rid of it. I can catch you on Monday to see it live if you prefer to. Yeah but how to generate them? I mean one-time generation is not big deal, but hand editing it when we change deps is not feasible. We would need to setup dedicated boxes just for that... Thanks for interesting points! -- Later, Lukas "lzap" Zapletal

On 08/05/2011 02:51 PM, Vít Ondruch wrote: I just opened The Rails 3 Way book this evening, was going to start reading (received it yesterday) and the first chapter is about - guess what - Bundler. There's very interesting statement in regard to our issue that basically says it's easy to turn off Bundler support in Rails 3 app. You have to delete Gemfile and that's it. It will fallback. Tried it now and it does not work for me. It says it cant find gettext now, but after I add missing require line I am able to start the server. Good news. -- Later, Lukas "lzap" Zapletal

On 08/05/2011 08:13 AM, Vít Ondruch wrote: 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? -Mo

Well in the upstream codebase we would target whichever version of the gem the app depends on, eg 1.0.1 until we test / deploy against 1.0.2 at which point we update the Gemfile.lock in git. After that when submitting the package to F15, we would need to include a patch to revert the dependency in Gemfile.lock to 1.0.1 We often patch the gem specs anyways to manipulate the dependencies to conform to the versions in Fedora [1] [2] [3] I agree it might just be simpler to remove bundler, though there is value in conforming to upstream practices as much as we can. The consensus of the Fedora/Ruby community is fine w/ me on this one. -Mo [1] http://pkgs.fedoraproject.org/gitweb/?p=rubygem-actionpack.git;a=blob;f=a... [2] http://pkgs.fedoraproject.org/gitweb/?p=rubygem-text-format.git;a=blob;f=... [3] http://pkgs.fedoraproject.org/gitweb/?p=rubygem-actionmailer.git;a=blob;f...

On Mon, Aug 8, 2011 at 12:00 PM, Chris Lalancette <clalance(a)redhat.com&gt; wrote: 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

On 08/09/2011 02:30 PM, Chris Lalancette wrote: This is basically what I describe as "got rid of Bundler itself". I would not remove it from git, but only in the RPM. I just found it's not as easy as it looks like. Rails 3 is giving require errors than. -- Later, Lukas "lzap" Zapletal

Or, instead of what I mentioned earlier, can Fedora stand up its own rubygems server and then point to that instead of the default so we can control security? We can then have a hook in gem that says "when a user downloads this gem, gem2rpm is and install it as an RPM" ========= Tyler Smart Check out the IT.rb group: https://docspace.corp.redhat.com/groups/itrb

Option 3 is my suggestion too. -- Ing.Guillermo Gomez S. Fedora Board Member A4 http://gomix.fedora-ve.org http://www.neotechgw.com

On 08/08/2011 04:37 PM, Ohad Levy wrote: According to the Rails 3 Way book the only thing is to remove Gemfile* files and that's it. Unfortunately Rails 3 then starts screaming about unknown constants (unrequired files). It can take some time to fix it and can be difficult for developers to keep requires up-to-date (since they are using Bundler). -- Later, Lukas "lzap" Zapletal

On Wed, Aug 10, 2011 at 9:03 AM, Chris Lalancette <clalance(a)redhat.com&gt; wrote: That seems like a reasonable first pass to me too, I'll give it a try today on conductor and see how it goes. If it works, it would be nice to have those requires in one place (some kind of template that gets pulled in directly or transformed into a Gemfile perhaps). -j

On Wed, Aug 10, 2011 at 9:29 AM, Lukas Zapletal <lzap+fed(a)redhat.com&gt; wrote: FYI, I tried this today, and it seems to work. I set an env variable to toggle use of bundler, and added requires that only get called if you are not using bundler. One difference to note is that some libraries have different names than their gems. For instance, in you Gemfile, you might have: gem 'compass-960-plugin', :require => 'ninesixty' but in your require, you would need: require 'ninesixty' There could be other speed bumps, but so far so good on this.

Dne 10.8.2011 15:03, Chris Lalancette napsal(a): What about something like "fake-bundler" which would implement the Bundler DSL to allow execution of the Gemfile, but it would just require the gems? I mean the "fake-bundler" does not exist, but it should not be that hard to write it IMO :) Vit

On 08/11/2011 03:17 PM, Chris Lalancette wrote: +1 for the same syntax. That would ease things... -- Later, Lukas "lzap" Zapletal