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
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@redhat.com To: ruby-sig@lists.fedoraproject.org, katello-devel@redhat.com Cc: "Jan Blazek" jblazek@redhat.com, "Justin Sherrill" jsherril@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
On 08/05/2011 02:11 PM, Tyler Smart wrote:
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.
Interesting idea, but as Vita said later in the thread - RPMs are a must.
Thanks for tips!
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@redhat.com To: ruby-sig@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:
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.
Interesting idea, but as Vita said later in the thread - RPMs are a must.
Thanks for tips!
On Fri, Aug 05, 2011 at 04:12:25PM +0200, Lukas Zapletal wrote:
On 08/05/2011 02:11 PM, Tyler Smart wrote:
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.
Interesting idea, but as Vita said later in the thread - RPMs are a must.
Thanks for tips!
Sorry to come into the discussion late, but after talking with Tyler this morning I'd like to participate in this (since the convergence of RPM and GEM is a source of frustration for me).
The problem I see is that RPM and GEM are not compatible enough for distributing GEMs properly. Specifically, you can't install two versions of an RPM (such as rubygem-rails) while GEM absolutely allows this sort of side-by-side installation. The same problem exists for other dependency systems such as Maven.
Is there any way to evolve RPM to handle this sort of scenario?
On Fri, Aug 05, 2011 at 10:27:03AM -0400, Darryl L. Pierce wrote:
On Fri, Aug 05, 2011 at 04:12:25PM +0200, Lukas Zapletal wrote:
On 08/05/2011 02:11 PM, Tyler Smart wrote:
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.
Interesting idea, but as Vita said later in the thread - RPMs are a must.
Thanks for tips!
Sorry to come into the discussion late, but after talking with Tyler this morning I'd like to participate in this (since the convergence of RPM and GEM is a source of frustration for me).
The problem I see is that RPM and GEM are not compatible enough for distributing GEMs properly. Specifically, you can't install two versions of an RPM (such as rubygem-rails) while GEM absolutely allows this sort of side-by-side installation. The same problem exists for other dependency systems such as Maven.
Is there any way to evolve RPM to handle this sort of scenario?
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
On Fri, Aug 05, 2011 at 10:30:02AM -0400, Hugh Brock 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).
I've not dealt with RVM to date (tried it once, it didn't work, I didn't bother going back to the well) but understand more or less what it's going for.
Is there any way to evolve RPM to handle this sort of scenario?
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
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
On Mon, Aug 08, 2011 at 11:41:28AM -0400, Mo Morsi wrote:
Is there any way to evolve RPM to handle this sort of scenario?
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
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)
The downside to that is that every new release of a gem will require 1) a new package and 2) a new package review since the name is now directly coupled to the version of the gem.
The downside to that is that every new release of a gem will require 1) a new package and 2) a new package review since the name is now directly coupled to the version of the gem.
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
On Mon, Aug 08, 2011 at 12:05:36PM -0400, Mo Morsi wrote:
The downside to that is that every new release of a gem will require 1) a new package and 2) a new package review since the name is now directly coupled to the version of the gem.
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).
I see that as the problem; i.e., there won't ever be a single stack that everybody wants to (or can) use. We need some flexibility so that someone can, for example, keep using Rails 2.3 on a later Fedora; i.e., there's no reason they should have to migrate to 3.0 just to get a newer Fedora release.
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@redhat.com To: ruby-sig@lists.fedoraproject.org Sent: Monday, August 8, 2011 12:05:36 PM Subject: Re: Distributing Rails 3 apps
The downside to that is that every new release of a gem will require 1) a new package and 2) a new package review since the name is now directly coupled to the version of the gem.
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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
Dne 5.8.2011 16:27, Darryl L. Pierce napsal(a):
On Fri, Aug 05, 2011 at 04:12:25PM +0200, Lukas Zapletal wrote:
On 08/05/2011 02:11 PM, Tyler Smart wrote:
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.
Interesting idea, but as Vita said later in the thread - RPMs are a must.
Thanks for tips!
Sorry to come into the discussion late, but after talking with Tyler this morning I'd like to participate in this (since the convergence of RPM and GEM is a source of frustration for me).
The problem I see is that RPM and GEM are not compatible enough for distributing GEMs properly. Specifically, you can't install two versions of an RPM (such as rubygem-rails) while GEM absolutely allows this sort of side-by-side installation. The same problem exists for other dependency systems such as Maven.
This is not exact. RPM allows to install different versions of package on single system, but yum disallows it.
Is there any way to evolve RPM to handle this sort of scenario?
ruby-sig mailing list ruby-sig@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:
Dne 5.8.2011 16:27, Darryl L. Pierce napsal(a):
On Fri, Aug 05, 2011 at 04:12:25PM +0200, Lukas Zapletal wrote:
On 08/05/2011 02:11 PM, Tyler Smart wrote:
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.
Interesting idea, but as Vita said later in the thread - RPMs are a must.
Thanks for tips!
Sorry to come into the discussion late, but after talking with Tyler this morning I'd like to participate in this (since the convergence of RPM and GEM is a source of frustration for me).
The problem I see is that RPM and GEM are not compatible enough for distributing GEMs properly. Specifically, you can't install two versions of an RPM (such as rubygem-rails) while GEM absolutely allows this sort of side-by-side installation. The same problem exists for other dependency systems such as Maven.
This is not exact. RPM allows to install different versions of package on single system, but yum disallows it.
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.
Dne 5.8.2011 17:03, Darryl L. Pierce napsal(a):
On Fri, Aug 05, 2011 at 04:32:04PM +0200, Vít Ondruch wrote:
Dne 5.8.2011 16:27, Darryl L. Pierce napsal(a):
On Fri, Aug 05, 2011 at 04:12:25PM +0200, Lukas Zapletal wrote:
On 08/05/2011 02:11 PM, Tyler Smart wrote:
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.
Interesting idea, but as Vita said later in the thread - RPMs are a must.
Thanks for tips!
Sorry to come into the discussion late, but after talking with Tyler this morning I'd like to participate in this (since the convergence of RPM and GEM is a source of frustration for me).
The problem I see is that RPM and GEM are not compatible enough for distributing GEMs properly. Specifically, you can't install two versions of an RPM (such as rubygem-rails) while GEM absolutely allows this sort of side-by-side installation. The same problem exists for other dependency systems such as Maven.
This is not exact. RPM allows to install different versions of package on single system, but yum disallows it.
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?
Once you install two versions, you cannot relay o RPM updates anymore and they have to be solved by some external utility.
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.
I just tried it today and if the files are the same, it just works (the files are the same as long as they are generated by the same version of RubyGems). However I did not try to install two files with different content ...
ruby-sig mailing list ruby-sig@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
On Fri, Aug 05, 2011 at 05:12:23PM +0200, Vít Ondruch wrote:
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?
Once you install two versions, you cannot relay o RPM updates anymore and they have to be solved by some external utility.
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).
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.
I just tried it today and if the files are the same, it just works (the files are the same as long as they are generated by the same version of RubyGems). However I did not try to install two files with different content ...
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?
Just to be clear:
We are talking about 1) coming up with a solution (possibly multiple) 2) Proposing this to whomever listens at Fedora
I am new to the Fedora landscape so please be patient with me.
========= Tyler Smart Check out the IT.rb group: https://docspace.corp.redhat.com/groups/itrb
----- Original Message ----- From: "Darryl L. Pierce" dpierce@redhat.com To: "Ruby SIG mailing list" ruby-sig@lists.fedoraproject.org Sent: Friday, August 5, 2011 1:13:12 PM Subject: Re: Distributing Rails 3 apps
On Fri, Aug 05, 2011 at 05:12:23PM +0200, Vít Ondruch wrote:
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?
Once you install two versions, you cannot relay o RPM updates anymore and they have to be solved by some external utility.
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).
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.
I just tried it today and if the files are the same, it just works (the files are the same as long as they are generated by the same version of RubyGems). However I did not try to install two files with different content ...
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?
On Fri, Aug 05, 2011 at 01:19:24PM -0400, Tyler Smart wrote:
Just to be clear:
We are talking about
- coming up with a solution (possibly multiple)
- Proposing this to whomever listens at Fedora
I am new to the Fedora landscape so please be patient with me.
Yes, pretty much.
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.
- 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.
- 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?
- 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
- 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
On 08/05/2011 02:13 PM, Vít Ondruch wrote:
Option 3 is my favorite. I am doing so in many packaged gems, which relays on Bundler for the test suite execution.
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.
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
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!
Dne 5.8.2011 14:41, Lukas Zapletal napsal(a):
On 08/05/2011 02:13 PM, Vít Ondruch wrote:
Option 3 is my favorite. I am doing so in many packaged gems, which relays on Bundler for the test suite execution.
I knew there is somebody with the knowledge HOW to do it! Cool.
Actually I've never tried with Rails, but here is described how Rails works with Bundler:
http://yehudakatz.com/2011/05/30/gem-versioning-and-bundler-doing-it-right/
In gems or test suites, it is usually enough to fine "require 'bundler'" in sources and just remove it and thats it. It might be, however, a bit different with Rails.
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.
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
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!
On 08/05/2011 02:51 PM, Vít Ondruch wrote:
Actually I've never tried with Rails, but here is described how Rails works with Bundler:
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.
Dne 5.8.2011 21:27, Lukas Zapletal napsal(a):
On 08/05/2011 02:51 PM, Vít Ondruch wrote:
Actually I've never tried with Rails, but here is described how Rails works with Bundler:
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.
Yes, it has to be like that, since Bundler requires all the gem it lists.
Vit
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?
-Mo
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.
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?
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=acti...
[2] http://pkgs.fedoraproject.org/gitweb/?p=rubygem-text-format.git;a=blob;f=rem...
[3] http://pkgs.fedoraproject.org/gitweb/?p=rubygem-actionmailer.git;a=blob;f=ac...
On 08/08/2011 06:44 PM, Mo Morsi wrote:
We often patch the gem specs anyways to manipulate the dependencies to conform to the versions in Fedora [1] [2] [3]
Hey,
first of all I would like to put a remark of me writing about changing an upstream Rails 3 project for easy deployment. You are writing about general rules of Rails 3 apps packaging. We have slightly different angle of view. But basically it's the same thing ;-)
I am not fun of generated patches. It seems these were created by generating "correct" lockfile and diffing it against the one in the upstream. This can be really painful process doing that for each Fedora version. Once the upstream issues "bundle update" the patch is incorrect and must be regenerated from scratch.
I understand there is no easy way of regenerating the lock file during the RPM build, since we need all the dependencies installed as BuildRequires. But isn't there better (or less painful) process for that? I can hardly imagine manual updating such a patch.
So far we've been playing with:
a) Generating the lockfile using bundler in the SPEC file.
Pros: - works without human intervention
Cons: - the build environment must be rock solid - we must take care during dependency upgrades - each dep update = new app version release
b) Removing bundler from the app.
Pros: - no bundler, no problem
Cons: - can work only when the upstream project is Fedora-based - we are changing the app (and possibly it's behavior) - not there yet (too many requires missing)
c) Generating the lockfile each start
Pros: - easy trick - not changing the app - works with upgrades or different library versions
Cons: - start is a bit slower
d) Monkey-patching bundler just to ignore versions
Pros: - the ruby way (?) - pretty elegant - fast start - no lock file at all
Cons: - it's a hack - did not test it yet
e) Patching the lockfile for each Fedora version
Pros: - not changing bundler or app itself - no bundler during the build - pretty standard process
Cons: - more difficult to maintain - must take care when updating Gemfile.lock in the upstream
I think your recommendation (e) could work for pretty stable projects where dependencies does not change many often. For those which are in the early stage I can picture this:
* The upstream team should keep the version numbers as close as possible to the oldest supported Fedora in the git Gemfile.lock.
* The upstream team must keep the build environment clean & up-to-date (e.g. using Koji). Outdated dependencies during the build lead to incorrect release (wrong lock file).
* The upstream team should have automated tests installing each release and checking bundler. If there is deviation found its corrected (using bundler install) and diff is sent to the mailing list to put it in the SPEC git repo.
If you have other best practices feel free to add them. I am trying to collect if this approach (e) is feasible for us.
In any case, would you accept a rails 3 app taking (c) or (d) approach to Fedora?
Many thanks
On Mon, Aug 8, 2011 at 12:00 PM, Chris Lalancette clalance@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
-j
On 08/08/11 - 05:23:18PM, Jason Guiditta wrote:
On Mon, Aug 8, 2011 at 12:00 PM, Chris Lalancette clalance@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 :).
On 08/09/2011 02:30 PM, Chris Lalancette wrote:
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 :).
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.
On 08/05/11 - 01:52:36PM, Lukas Zapletal wrote:
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.
We are starting to run into exactly this same problem with Aeolus, so this mail is very timely. We just switched *to* Bundler, but given your experience with it, I'm think I'm leaning in favor of 3) for Aeolus. Like you said, for rapid prototyping, Bundler is fine; for deployment, it seems to be a hassle.
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
Dne 5.8.2011 14:42, Tyler Smart napsal(a):
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 _______________________________________________ ruby-sig mailing list ruby-sig@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
This should be opposite ... RubyGems should support RPM and then we need just repository where will be all gems packaged as RPM. The RPM is a must.
Vit
Option 3 is my suggestion too.
- Unstitch bundler from the rails3 app
On 08/08/2011 04:37 PM, Ohad Levy wrote:
- Unstitch bundler from the rails3 app
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).
On 08/10/11 - 10:02:41AM, Lukas Zapletal wrote:
On 08/08/2011 04:37 PM, Ohad Levy wrote:
- Unstitch bundler from the rails3 app
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).
I'll admit I haven't really looked in any detail, but my thought about how this would look is something like:
if use_bundler Bundler.require(:default, Rails.env) else require 'foo' require 'bar' require 'baz' ... end
But maybe that is too simplistic.
On Wed, Aug 10, 2011 at 9:03 AM, Chris Lalancette clalance@redhat.com wrote:
On 08/10/11 - 10:02:41AM, Lukas Zapletal wrote:
On 08/08/2011 04:37 PM, Ohad Levy wrote:
- Unstitch bundler from the rails3 app
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).
I'll admit I haven't really looked in any detail, but my thought about how this would look is something like:
if use_bundler Bundler.require(:default, Rails.env) else require 'foo' require 'bar' require 'baz' ... end
But maybe that is too simplistic.
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 08/10/2011 03:25 PM, Jason Guiditta wrote:
if use_bundler
Bundler.require(:default, Rails.env)else require 'foo' require 'bar' require 'baz' ... end
But maybe that is too simplistic.
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).
Yeah I tried this approach two days ago - and one of our initializers were screaming about unknown "_" method. I guess this had something to do with gettext, but I already had all our gettext modules required.
I gave up for now.
On Wed, Aug 10, 2011 at 9:29 AM, Lukas Zapletal lzap+fed@redhat.com wrote:
On 08/10/2011 03:25 PM, Jason Guiditta wrote:
if use_bundler
Bundler.require(:default, Rails.env) else require 'foo' require 'bar' require 'baz' ... end
But maybe that is too simplistic.
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).
Yeah I tried this approach two days ago - and one of our initializers were screaming about unknown "_" method. I guess this had something to do with gettext, but I already had all our gettext modules required.
I gave up for now.
-- Later, Lukas "lzap" Zapletal _______________________________________________
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.
On 08/10/2011 09:03 AM, Chris Lalancette wrote:
On 08/10/11 - 10:02:41AM, Lukas Zapletal wrote:
On 08/08/2011 04:37 PM, Ohad Levy wrote:
- Unstitch bundler from the rails3 app
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).
I'll admit I haven't really looked in any detail, but my thought about how this would look is something like:
if use_bundler Bundler.require(:default, Rails.env) else require 'foo' require 'bar' require 'baz' ... end
But maybe that is too simplistic.
One annoyance with this is that we have to keep the dep list in 2 places here -- the Gemfile and the individual requires list. Perhaps there's no way around this, though.
Scott
Dne 10.8.2011 15:03, Chris Lalancette napsal(a):
On 08/10/11 - 10:02:41AM, Lukas Zapletal wrote:
On 08/08/2011 04:37 PM, Ohad Levy wrote:
- Unstitch bundler from the rails3 app
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).
I'll admit I haven't really looked in any detail, but my thought about how this would look is something like:
if use_bundler Bundler.require(:default, Rails.env) else require 'foo' require 'bar' require 'baz' ... end
But maybe that is too simplistic.
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/11 - 12:21:01PM, Vít Ondruch wrote:
Dne 10.8.2011 15:03, Chris Lalancette napsal(a):
On 08/10/11 - 10:02:41AM, Lukas Zapletal wrote:
On 08/08/2011 04:37 PM, Ohad Levy wrote:
- Unstitch bundler from the rails3 app
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).
I'll admit I haven't really looked in any detail, but my thought about how this would look is something like:
if use_bundler Bundler.require(:default, Rails.env) else require 'foo' require 'bar' require 'baz' ... end
But maybe that is too simplistic.
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 :)
Yeah, Jay and I discussed that. It sounds like a good enhancement to the above proposal.
On 08/11/2011 03:17 PM, Chris Lalancette wrote:
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 :)
Yeah, Jay and I discussed that. It sounds like a good enhancement to the above proposal.
+1
for the same syntax. That would ease things...
ruby-sig@lists.fedoraproject.org
-
"Guillermo Gómez S." -
Chris Lalancette -
Darryl L. Pierce -
Hugh O. Brock -
jason.guiditta -
Lukas Zapletal -
Mo Morsi -
Ohad Levy -
Scott Seago -
Tyler Smart -
Vít Ondruch