Hello everybody,
I'd like to bring to your attention that there was proposed by Ruby SIG meeting as part of FUDCon Milan [1]. I would like to take this meeting as change to discuss Ruby future in Fedora. Here are few point I'd like to discuss:
* Ruby 1.9.3 for F17. I have already pre-prepared feature page [2] for this and I am working towards packaging Ruby 1.9.3. However, there are several issues including - How to correctly name and version subpackages such as RubyGems, RDoc, Rake, IRB - How to maintain updates of them late. - Directory structure.
* Support of gems for MRI and JRuby. - Is it possible to share RubyGems? - Is it possible to share gems?
* Support of multiple versions of gems on single installation, e.g. Rails 2 vs Rails 3.
* Refresh of Ruby Packaging Guidelines - They do not always follow best practices - They will need to be updated because of Ruby 1.9.3
* gem2rpm future and possible extensions
This is list is not exhaustive, so please feel free to add few more points, which you think might be interesting to discuss.
Vit
[1] https://fedoraproject.org/wiki/FUDCon:Milan_2011 [2] https://fedoraproject.org/wiki/Features/Ruby_1.9.3
Dne 21.9.2011 13:43, Vít Ondruch napsal(a):
Hello everybody,
I'd like to bring to your attention that there was proposed by Ruby SIG meeting as part of FUDCon Milan [1]. I would like to take this meeting as change to discuss Ruby future in Fedora. Here are few point I'd like to discuss:
- Ruby 1.9.3 for F17. I have already pre-prepared feature page [2] for
this and I am working towards packaging Ruby 1.9.3. However, there are several issues including - How to correctly name and version subpackages such as RubyGems, RDoc, Rake, IRB - How to maintain updates of them late. - Directory structure.
Support of gems for MRI and JRuby.
- Is it possible to share RubyGems?
- Is it possible to share gems?
Support of multiple versions of gems on single installation, e.g.
Rails 2 vs Rails 3.
Refresh of Ruby Packaging Guidelines
- They do not always follow best practices
- They will need to be updated because of Ruby 1.9.3
gem2rpm future and possible extensions
This is list is not exhaustive, so please feel free to add few more points, which you think might be interesting to discuss.
Vit
[1] https://fedoraproject.org/wiki/FUDCon:Milan_2011 [2] https://fedoraproject.org/wiki/Features/Ruby_1.9.3 _______________________________________________ ruby-sig mailing list ruby-sig@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
I have to add few more points immediately:
* Rails 3.1 for F17
* Migration of RSpec to RSpec 2.x
Vit
On 09/21/2011 07:46 AM, Vít Ondruch wrote:
Dne 21.9.2011 13:43, Vít Ondruch napsal(a):
Hello everybody,
I'd like to bring to your attention that there was proposed by Ruby SIG meeting as part of FUDCon Milan [1]. I would like to take this meeting as change to discuss Ruby future in Fedora. Here are few point I'd like to discuss:
- Ruby 1.9.3 for F17. I have already pre-prepared feature page [2] for
this and I am working towards packaging Ruby 1.9.3. However, there are several issues including - How to correctly name and version subpackages such as RubyGems, RDoc, Rake, IRB - How to maintain updates of them late. - Directory structure.
Awesome! It's looking like Ruby 1.8 is quickly going the way of the dinosaur so I propose we just bite the bullet and update the main ruby package to 1.9. Then we can update all gems to the latest versions and/or the versions required to work with Ruby 1.9
If we still want to ship Ruby 1.8 I propose we simply fork off a compat-ruby-1.8 package and ship any additional compat packages for older versions of gems we want to ship.
- Support of gems for MRI and JRuby. - Is it possible to share RubyGems? - Is it possible to share gems?
Its difficult since the gems themselves depend on the rubygems package which depends on MRI. Perhaps if we can break this dependency somehow this would be more feasible.
Just thought of a random idea, would the rubygems package be able to _not_ depend on a specific package, rather depend a 'ruby-interpreter' capability, which then would be provided by both the MRI and JRuby packages? Then MRI / JRuby could be swapped in / out and any gem that depends on a specific interpreter could have the MRI/JRuby dependency there instead having it in rubygems.
Granted this would make it more difficult to install both MRI and JRuby at the same time on the same system, though it may be feasible, just haven't thought this one through.
- Support of multiple versions of gems on single installation, e.g.
Rails 2 vs Rails 3.
We just need to ship a compat-rubygem-rails2 package and we should be good on this front.
- Refresh of Ruby Packaging Guidelines - They do not always follow best practices - They will need to be updated because of Ruby 1.9.3
Agreed, be sure to keep us posted with any new ideas ya'll come up with. Going forward I think we should have a Ruby presence at all FUDCons. Probably won't be able to make Milan, but will try to make Blacksburg this January [1] (would be good to get away from the frigid Syracuse winter ;-) ).
- gem2rpm future and possible extensions
Yes, yes, and more yes! :-)
We need to automate the gem -> rpm process, I am 100% confident that we can develop tooling to do so. Will alleviate alot of the hasstle w/ Ruby / Fedora integration going forward.
I have to add few more points immediately:
- Rails 3.1 for F17
I still would like to hold off on this, we just updated to Rails 3 and I haven't seen much 3.1 adoption upstream yet. Maybe we can relook at this for F18 or F19.
- Migration of RSpec to RSpec 2.x
This sounds reasonable as most new projects are using RSpec 2 nowadays. We most likely will still need to ship a compat-rspec1 package for those which haven't yet updated yet, though we can use this as an opportunity for the Fedora community to reach out and help those projects update.
Really appreciate all of this,
-Mo
- Refresh of Ruby Packaging Guidelines - They do not always follow best practices - They will need to be updated because of Ruby 1.9.3
Agreed, be sure to keep us posted with any new ideas ya'll come up with. Going forward I think we should have a Ruby presence at all FUDCons. Probably won't be able to make Milan, but will try to make Blacksburg this January [1] (would be good to get away from the frigid Syracuse winter ;-) ).
Err sorry forgot to include the link
-Mo
On Wed, Sep 21, 2011 at 11:45:45AM -0400, Mo Morsi wrote:
- gem2rpm future and possible extensions
Yes, yes, and more yes! :-)
We need to automate the gem -> rpm process, I am 100% confident that we can develop tooling to do so. Will alleviate alot of the hasstle w/ Ruby / Fedora integration going forward.
The IT.rb group here in Raleigh had a design session around this very piece, but AFAIK has moved beyond the discussion phase.
I have to add few more points immediately:
- Rails 3.1 for F17
I still would like to hold off on this, we just updated to Rails 3 and I haven't seen much 3.1 adoption upstream yet. Maybe we can relook at this for F18 or F19.
This is a small part of what I mention above. One of the things we discussed was a complete separation of things like specific versions of Rails (and other gems) from version of Fedora. IOW, why should F14 be Rails 3.1? Why not let us run Fedora 17 with whatever version of Rails we choose?
Yes I have started a project to alleviate the pain mentioned below, and will be continuing it in my lunchtime to get a working demo.
----- Original Message ----- From: "Darryl L. Pierce" dpierce@redhat.com To: "Ruby SIG mailing list" ruby-sig@lists.fedoraproject.org Sent: Wednesday, September 21, 2011 1:28:35 PM Subject: Re: FUDCon:Milan 2011 - Ruby SIG meeting
On Wed, Sep 21, 2011 at 11:45:45AM -0400, Mo Morsi wrote:
- gem2rpm future and possible extensions
Yes, yes, and more yes! :-)
We need to automate the gem -> rpm process, I am 100% confident that we can develop tooling to do so. Will alleviate alot of the hasstle w/ Ruby / Fedora integration going forward.
The IT.rb group here in Raleigh had a design session around this very piece, but AFAIK has moved beyond the discussion phase.
I have to add few more points immediately:
- Rails 3.1 for F17
I still would like to hold off on this, we just updated to Rails 3 and I haven't seen much 3.1 adoption upstream yet. Maybe we can relook at this for F18 or F19.
This is a small part of what I mention above. One of the things we discussed was a complete separation of things like specific versions of Rails (and other gems) from version of Fedora. IOW, why should F14 be Rails 3.1? Why not let us run Fedora 17 with whatever version of Rails we choose?
On 09/21/2011 01:51 PM, Tyler Smart wrote:
Yes I have started a project to alleviate the pain mentioned below, and will be continuing it in my lunchtime to get a working demo.
Great! Remember the open source mantra, release early, release often [1]
I also started this project [2] a while back to help w/ the process but don't currently have the cycles to work on it, if anyone wants to pick it up, the code is out there!
Yes, yes, and more yes! :-)
We need to automate the gem -> rpm process, I am 100% confident that we can develop tooling to do so. Will alleviate alot of the hasstle w/ Ruby / Fedora integration going forward.
The IT.rb group here in Raleigh had a design session around this very piece, but AFAIK has moved beyond the discussion phase.
Cool, any chance you guys could summarize meeting notes and what ya'll are working on. I'm sure alot of us in other parts of the world would love to help you w/ your efforts :-)
I have to add few more points immediately:
- Rails 3.1 for F17
I still would like to hold off on this, we just updated to Rails 3 and I haven't seen much 3.1 adoption upstream yet. Maybe we can relook at this for F18 or F19.
This is a small part of what I mention above. One of the things we discussed was a complete separation of things like specific versions of Rails (and other gems) from version of Fedora. IOW, why should F14 be Rails 3.1? Why not let us run Fedora 17 with whatever version of Rails we choose?
Not sure if I'm following, you can always gem install any version of any gem you choose. We are talking about the single supported stack in Fedora.
Alternatively I've run across this project [3] but have yet to mess around with it. It might be a way to setup parallel stacks of gem rpms for use by Fedora users.
-Mo
[1] http://en.wikipedia.org/wiki/Release_early,_release_often [2] https://github.com/movitto/polisher [3] http://fedoraproject.org/wiki/Category:Copr
On Wed, Sep 21, 2011 at 03:02:10PM -0400, Mo Morsi wrote:
This is a small part of what I mention above. One of the things we discussed was a complete separation of things like specific versions of Rails (and other gems) from version of Fedora. IOW, why should F14 be Rails 3.1? Why not let us run Fedora 17 with whatever version of Rails we choose?
Not sure if I'm following, you can always gem install any version of any gem you choose. We are talking about the single supported stack in Fedora.
I'm talking about completely separating Ruby gems from Fedora. So, for example, installing Fedora XX won't require rubygem-rails yy.xx. Insteadl, _all_ Ruby gems would be kept in a separate, optional yum repository. Then you could maintain the gems separately.
So if you're app requires Rails 2.3.11 and farkle 3.1, even though those aren't the latest, then you could install them without having to hunt down, grab and install the RPMs (and then do the same for all dependencies) manually. The one repositoryw ould have 2.3.8, 2.3.11, 3.0.0, 3.1.0, etc. and all dependent versions available.
On Thu, Sep 22, 2011 at 01:37:33PM -0400, Darryl L. Pierce wrote:
On Wed, Sep 21, 2011 at 03:02:10PM -0400, Mo Morsi wrote:
This is a small part of what I mention above. One of the things we discussed was a complete separation of things like specific versions of Rails (and other gems) from version of Fedora. IOW, why should F14 be Rails 3.1? Why not let us run Fedora 17 with whatever version of Rails we choose?
Not sure if I'm following, you can always gem install any version of any gem you choose. We are talking about the single supported stack in Fedora.
I'm talking about completely separating Ruby gems from Fedora. So, for example, installing Fedora XX won't require rubygem-rails yy.xx. Insteadl, _all_ Ruby gems would be kept in a separate, optional yum repository. Then you could maintain the gems separately.
So if you're app requires Rails 2.3.11 and farkle 3.1, even though those aren't the latest, then you could install them without having to hunt down, grab and install the RPMs (and then do the same for all dependencies) manually. The one repositoryw ould have 2.3.8, 2.3.11, 3.0.0, 3.1.0, etc. and all dependent versions available.
This is probably going to give fedora packagers massive heartburn, but I think Darryl is on the right track here.
To really make this work you also need a way to install multiple stacks of gems on the same machine. So I need for example to be able to have two different Rails apps installed, each of which may depend on different and conflicting package sets, and have everything work and be happy. As horrible as this is from a support standpoint, it is the way the Ruby world works, and trying to get away from it is swimming upstream...
/me ducks large rocks
--Hugh
On Thu, Sep 22, 2011 at 01:52:38PM -0400, Hugh Brock wrote:
I'm talking about completely separating Ruby gems from Fedora. So, for example, installing Fedora XX won't require rubygem-rails yy.xx. Insteadl, _all_ Ruby gems would be kept in a separate, optional yum repository. Then you could maintain the gems separately.
So if you're app requires Rails 2.3.11 and farkle 3.1, even though those aren't the latest, then you could install them without having to hunt down, grab and install the RPMs (and then do the same for all dependencies) manually. The one repositoryw ould have 2.3.8, 2.3.11, 3.0.0, 3.1.0, etc. and all dependent versions available.
This is probably going to give fedora packagers massive heartburn, but I think Darryl is on the right track here.
To really make this work you also need a way to install multiple stacks of gems on the same machine. So I need for example to be able to have two different Rails apps installed, each of which may depend on different and conflicting package sets, and have everything work and be happy. As horrible as this is from a support standpoint, it is the way the Ruby world works, and trying to get away from it is swimming upstream...
Kernel packages are already supported this way. Actually RPM will let you install multiple versions of the same base-named RPM by doing an install rather than an update.
The big picture we had was to have a package group called "Ruby Developer" that would install a few things, like define a Yum repo for the supported Ruby gems repo, install a yum{ex} plugin that would handle installing the multiple versions of gem (and could be abstracted to handle the same situation with Python eggs and Java jars), etc.
As for the Ruby gem repo, what we talked about there was a server that would act as a staging area for moving gems into a supported state. It would have an application that would regularly scour RubyGems.org for the latest versions of all gems. Any that it finds that 1) are not already packaged on the gem server or 2) are not already maintained by a package maintainer would be downloaded and an attempt to wrap it as an RPM made. This would let Ruby developers point to it for work without having to track down the dependencies themselves. (and yes, we realize this automated system is going to have failures that we can fix as we go)
The nice thing here is that, if you're going to use a gem that's not being maintained, it would be one step away from being adopted. The developer could go to the repo, select the gem RPM and submit it to the package approval process. The SRPM and SPEC would already exist, so it's just a matter of tweaking it.
I'm sure there are a lot of edge cases in this that need to be addressed. But the overall goal of getting Ruby gems into a state where Ruby developers on Fedora can consume them is attainable along lines like this.
/me ducks large rocks
Hit them back with a halibut!
Dne 22.9.2011 20:09, Darryl L. Pierce napsal(a):
On Thu, Sep 22, 2011 at 01:52:38PM -0400, Hugh Brock wrote:
I'm talking about completely separating Ruby gems from Fedora. So, for example, installing Fedora XX won't require rubygem-rails yy.xx. Insteadl, _all_ Ruby gems would be kept in a separate, optional yum repository. Then you could maintain the gems separately.
So if you're app requires Rails 2.3.11 and farkle 3.1, even though those aren't the latest, then you could install them without having to hunt down, grab and install the RPMs (and then do the same for all dependencies) manually. The one repositoryw ould have 2.3.8, 2.3.11, 3.0.0, 3.1.0, etc. and all dependent versions available.
You don't need more repositories. One repository can contain package in several versions as far as I know, but YUM is going to install the newest one. RPM allows to install several versions of single package on single computer, but you have to avoid conflicts while you are preparing the package. That works for plain Ruby gems, but it fails with binary gems. See the packaging guidelines.
This is probably going to give fedora packagers massive heartburn, but I think Darryl is on the right track here.
To really make this work you also need a way to install multiple stacks of gems on the same machine. So I need for example to be able to have two different Rails apps installed, each of which may depend on different and conflicting package sets, and have everything work and be happy. As horrible as this is from a support standpoint, it is the way the Ruby world works, and trying to get away from it is swimming upstream...
Kernel packages are already supported this way. Actually RPM will let you install multiple versions of the same base-named RPM by doing an install rather than an update.
The big picture we had was to have a package group called "Ruby Developer" that would install a few things, like define a Yum repo for the supported Ruby gems repo, install a yum{ex} plugin that would handle installing the multiple versions of gem (and could be abstracted to handle the same situation with Python eggs and Java jars), etc.
As for the Ruby gem repo, what we talked about there was a server that would act as a staging area for moving gems into a supported state. It would have an application that would regularly scour RubyGems.org for the latest versions of all gems. Any that it finds that 1) are not already packaged on the gem server or 2) are not already maintained by a package maintainer would be downloaded and an attempt to wrap it as an RPM made. This would let Ruby developers point to it for work without having to track down the dependencies themselves. (and yes, we realize this automated system is going to have failures that we can fix as we go)
While I like the automated idea, it aims too high IMO. For us, it would be sufficient to keep the previous versions of packages in the repository. That's it. It might not contain every Rails version, or every gem version you can think about, but it will contain just valid packages, the packages somebody took care about.
The nice thing here is that, if you're going to use a gem that's not being maintained, it would be one step away from being adopted. The developer could go to the repo, select the gem RPM and submit it to the package approval process. The SRPM and SPEC would already exist, so it's just a matter of tweaking it.
I'm sure there are a lot of edge cases in this that need to be addressed. But the overall goal of getting Ruby gems into a state where Ruby developers on Fedora can consume them is attainable along lines like this.
/me ducks large rocks
Hit them back with a halibut!
ruby-sig mailing list ruby-sig@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
On Fri, Sep 23, 2011 at 09:47:32AM +0200, Vít Ondruch wrote:
Dne 22.9.2011 20:09, Darryl L. Pierce napsal(a):
On Thu, Sep 22, 2011 at 01:52:38PM -0400, Hugh Brock wrote:
I'm talking about completely separating Ruby gems from Fedora. So, for example, installing Fedora XX won't require rubygem-rails yy.xx. Insteadl, _all_ Ruby gems would be kept in a separate, optional yum repository. Then you could maintain the gems separately.
So if you're app requires Rails 2.3.11 and farkle 3.1, even though those aren't the latest, then you could install them without having to hunt down, grab and install the RPMs (and then do the same for all dependencies) manually. The one repositoryw ould have 2.3.8, 2.3.11, 3.0.0, 3.1.0, etc. and all dependent versions available.
You don't need more repositories. One repository can contain package in several versions as far as I know, but YUM is going to install the newest one.
But it can be told to not do that in certain cases. For example, look at how kernels are handled. They're all named "kernel" but yum will do an install rather than an upgrade when dropping a new one on the system.
RPM allows to install several versions of single package on single computer, but you have to avoid conflicts while you are preparing the package. That works for plain Ruby gems, but it fails with binary gems. See the packaging guidelines.
Okay, I can see some potential problems there if a native gem has a dependency on a library that's only available in the main Fedora repos. This would be one of those edge cases I was talking about that would need to be addressed. :)
The big picture we had was to have a package group called "Ruby Developer" that would install a few things, like define a Yum repo for the supported Ruby gems repo, install a yum{ex} plugin that would handle installing the multiple versions of gem (and could be abstracted to handle the same situation with Python eggs and Java jars), etc.
As for the Ruby gem repo, what we talked about there was a server that would act as a staging area for moving gems into a supported state. It would have an application that would regularly scour RubyGems.org for the latest versions of all gems. Any that it finds that 1) are not already packaged on the gem server or 2) are not already maintained by a package maintainer would be downloaded and an attempt to wrap it as an RPM made. This would let Ruby developers point to it for work without having to track down the dependencies themselves. (and yes, we realize this automated system is going to have failures that we can fix as we go)
While I like the automated idea, it aims too high IMO.
Always aim high. :)
For us, it would be sufficient to keep the previous versions of packages in the repository. That's it. It might not contain every Rails version, or every gem version you can think about, but it will contain just valid packages, the packages somebody took care about.
I think that's insufficient. The goal is to make available all versions so that someone who has a specific need can fulfill it. Keep n and n-1 just pushes back the problem by one release.
Darryl L. Pierce wrote:
On Fri, Sep 23, 2011 at 09:47:32AM +0200, Vít Ondruch wrote:
Dne 22.9.2011 20:09, Darryl L. Pierce napsal(a):
On Thu, Sep 22, 2011 at 01:52:38PM -0400, Hugh Brock wrote:
I'm talking about completely separating Ruby gems from Fedora. So, for example, installing Fedora XX won't require rubygem-rails yy.xx. Insteadl, _all_ Ruby gems would be kept in a separate, optional yum repository. Then you could maintain the gems separately.
So if you're app requires Rails 2.3.11 and farkle 3.1, even though those aren't the latest, then you could install them without having to hunt down, grab and install the RPMs (and then do the same for all dependencies) manually. The one repositoryw ould have 2.3.8, 2.3.11, 3.0.0, 3.1.0, etc. and all dependent versions available.
You don't need more repositories. One repository can contain package in several versions as far as I know, but YUM is going to install the newest one.
But it can be told to not do that in certain cases. For example, look at how kernels are handled. They're all named "kernel" but yum will do an install rather than an upgrade when dropping a new one on the system.
During the initial 'yum install' however, YUM will automatically select the latest version as the best candidate - this has been demonstrated with providing multiple versions of kernel packages in anaconda installations with the "release" and "updates" repository enabled.
We also have to consider the implications of making this an add-on repository. Koji build target tags will have to point to different target tags, so that mashing can pick it up, of which a different configuration would be required to include all versions of all packages, and not just the latest (as is currently the case for the updates repository), not to mention the implications on Bodhi and PackageDB.
RPM allows to install several versions of single package on single computer, but you have to avoid conflicts while you are preparing the package. That works for plain Ruby gems, but it fails with binary gems. See the packaging guidelines.
Okay, I can see some potential problems there if a native gem has a dependency on a library that's only available in the main Fedora repos. This would be one of those edge cases I was talking about that would need to be addressed. :)
For most gems, compatibility with 1.8.5, 1.8.6, 1.8.7, 1.9.1 and 1.9.3 (supposedly) had not been a problem.
Binary gems, however, obviously need to be rebuild for various versions of Ruby. Luckily, Ruby has a search path that could be used for exactly this purpose. However, the packaging overhead would be significant - having to rebuild a binary gem package for "all" Ruby versions has limited sustainability. I have always looked for ways to have this building-against- multiple-versions be done automatically. I don't think it's completely infeasible, and can be accomplished with a plugin to Koji.
Kind regards,
-- kanarip
If you are deploying to production and point your prod servers at this external rubygems-rpm YUM repo, could you also not just lock the version of the rpm so that a yum update does not override your prod deployed version? Keeping binaries for every rubygem that we deem "code safe" in our repo would be a hassle to some degree, but I think far less of an issue than everyone in the world keeping separate yum repos of all the rpms needed for their deploy. Pooling resources would do the world a favor here ;)
Sure, Fedora could ship with a few of these rpms, the ones needed for a base deploy, but even then YUM will know not to remove those gems, but rather to install side-by-side gems when you launch your prod code.
Later on there might be an option for a "fedora-sanctioned" version of rpm that will keep separate gemsets through some magic not yet coded, but that's not what we're talking about now and probably will not need to talk about for a while.
----- Original Message -----
From: "Jeroen van Meeuwen" kanarip@kanarip.com To: ruby-sig@lists.fedoraproject.org Sent: Sunday, October 2, 2011 11:56:41 AM Subject: Re: FUDCon:Milan 2011 - Ruby SIG meeting
Darryl L. Pierce wrote:
On Fri, Sep 23, 2011 at 09:47:32AM +0200, Vít Ondruch wrote:
Dne 22.9.2011 20:09, Darryl L. Pierce napsal(a):
On Thu, Sep 22, 2011 at 01:52:38PM -0400, Hugh Brock wrote:
I'm talking about completely separating Ruby gems from Fedora. So, for example, installing Fedora XX won't require rubygem-rails yy.xx. Insteadl, _all_ Ruby gems would be kept in a separate, optional yum repository. Then you could maintain the gems separately.
So if you're app requires Rails 2.3.11 and farkle 3.1, even though those aren't the latest, then you could install them without having to hunt down, grab and install the RPMs (and then do the same for all dependencies) manually. The one repositoryw ould have 2.3.8, 2.3.11, 3.0.0, 3.1.0, etc. and all dependent versions available.
You don't need more repositories. One repository can contain package in several versions as far as I know, but YUM is going to install the newest one.
But it can be told to not do that in certain cases. For example, look at how kernels are handled. They're all named "kernel" but yum will do an install rather than an upgrade when dropping a new one on the system.
During the initial 'yum install' however, YUM will automatically select the latest version as the best candidate - this has been demonstrated with providing multiple versions of kernel packages in anaconda installations with the "release" and "updates" repository enabled.
We also have to consider the implications of making this an add-on repository. Koji build target tags will have to point to different target tags, so that mashing can pick it up, of which a different configuration would be required to include all versions of all packages, and not just the latest (as is currently the case for the updates repository), not to mention the implications on Bodhi and PackageDB.
RPM allows to install several versions of single package on single computer, but you have to avoid conflicts while you are preparing the package. That works for plain Ruby gems, but it fails with binary gems. See the packaging guidelines.
Okay, I can see some potential problems there if a native gem has a dependency on a library that's only available in the main Fedora repos. This would be one of those edge cases I was talking about that would need to be addressed. :)
For most gems, compatibility with 1.8.5, 1.8.6, 1.8.7, 1.9.1 and 1.9.3 (supposedly) had not been a problem.
Binary gems, however, obviously need to be rebuild for various versions of Ruby. Luckily, Ruby has a search path that could be used for exactly this purpose. However, the packaging overhead would be significant - having to rebuild a binary gem package for "all" Ruby versions has limited sustainability. I have always looked for ways to have this building-against-multiple-versions be done automatically. I don't think it's completely infeasible, and can be accomplished with a plugin to Koji.
Kind regards,
-- kanarip
_______________________________________________ ruby-sig mailing list ruby-sig@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
On 09/22/2011 07:52 PM, Hugh Brock wrote:
On Thu, Sep 22, 2011 at 01:37:33PM -0400, Darryl L. Pierce wrote:
On Wed, Sep 21, 2011 at 03:02:10PM -0400, Mo Morsi wrote:
This is a small part of what I mention above. One of the things we discussed was a complete separation of things like specific versions of Rails (and other gems) from version of Fedora. IOW, why should F14 be Rails 3.1? Why not let us run Fedora 17 with whatever version of Rails we choose?
Not sure if I'm following, you can always gem install any version of any gem you choose. We are talking about the single supported stack in Fedora.
I'm talking about completely separating Ruby gems from Fedora. So, for example, installing Fedora XX won't require rubygem-rails yy.xx. Insteadl, _all_ Ruby gems would be kept in a separate, optional yum repository. Then you could maintain the gems separately.
So if you're app requires Rails 2.3.11 and farkle 3.1, even though those aren't the latest, then you could install them without having to hunt down, grab and install the RPMs (and then do the same for all dependencies) manually. The one repositoryw ould have 2.3.8, 2.3.11, 3.0.0, 3.1.0, etc. and all dependent versions available.
This is probably going to give fedora packagers massive heartburn, but I think Darryl is on the right track here.
To really make this work you also need a way to install multiple stacks of gems on the same machine. So I need for example to be able to have two different Rails apps installed, each of which may depend on different and conflicting package sets, and have everything work and be happy. As horrible as this is from a support standpoint, it is the way the Ruby world works, and trying to get away from it is swimming upstream...
/me ducks large rocks
--Hugh
Perhaps we can make something like rvm (or the more recent rbenv - which does seem simpler and more robust) central to the Fedora ruby strategy. They allow you to install multiple ruby versions with multiple gem stacks concurrently, and decide on a per-application basis what ruby stack to use. It would be good it if it was easy for Fedora users to install rvm/rbenv and multiple versions of ruby and rails via rpm and have it all work out of the box.
On the other hand, it may be worth going to great lengths to ensure we have a single well-supported stack in that works with all the ruby applications we package for Fedora. Perhaps we need to make one official Fedora-supported stack and meanwhile make it as easy as possible to install additional ruby versions + gemstacks concurrently, say, from third party repos.
Shoot. I didn't see this mail before I sent out the other mail I sent out.
On a side note related to this, I have packaged both ruby-build and rbenv for fedora, and are available here[1] and here[2].
The former is still waiting for approval from the fedora system, while the latter I need to open a review request for
[1] https://bugzilla.redhat.com/show_bug.cgi?id=735672 [2] http://tejas.fedorapeople.org/rbenv/rbenv.spec
On Fri, Sep 23, 2011 at 1:26 PM, Emanuel Rietveld codehotter@gmail.comwrote:
On 09/22/2011 07:52 PM, Hugh Brock wrote:
On Thu, Sep 22, 2011 at 01:37:33PM -0400, Darryl L. Pierce wrote:
On Wed, Sep 21, 2011 at 03:02:10PM -0400, Mo Morsi wrote:
This is a small part of what I mention above. One of the things we discussed was a complete separation of things like specific versions
of
Rails (and other gems) from version of Fedora. IOW, why should F14 be Rails 3.1? Why not let us run Fedora 17 with whatever version of Rails we choose?
Not sure if I'm following, you can always gem install any version of
any
gem you choose. We are talking about the single supported stack in
Fedora.
I'm talking about completely separating Ruby gems from Fedora. So, for example, installing Fedora XX won't require rubygem-rails yy.xx. Insteadl, _all_ Ruby gems would be kept in a separate, optional yum repository. Then you could maintain the gems separately.
So if you're app requires Rails 2.3.11 and farkle 3.1, even though those aren't the latest, then you could install them without having to hunt down, grab and install the RPMs (and then do the same for all dependencies) manually. The one repositoryw ould have 2.3.8, 2.3.11, 3.0.0, 3.1.0, etc. and all dependent versions available.
This is probably going to give fedora packagers massive heartburn, but I think Darryl is on the right track here.
To really make this work you also need a way to install multiple stacks of gems on the same machine. So I need for example to be able to have two different Rails apps installed, each of which may depend on different and conflicting package sets, and have everything work and be happy. As horrible as this is from a support standpoint, it is the way the Ruby world works, and trying to get away from it is swimming upstream...
/me ducks large rocks
--Hugh
Perhaps we can make something like rvm (or the more recent rbenv - which does seem simpler and more robust) central to the Fedora ruby strategy. They allow you to install multiple ruby versions with multiple gem stacks concurrently, and decide on a per-application basis what ruby stack to use. It would be good it if it was easy for Fedora users to install rvm/rbenv and multiple versions of ruby and rails via rpm and have it all work out of the box.
On the other hand, it may be worth going to great lengths to ensure we have a single well-supported stack in that works with all the ruby applications we package for Fedora. Perhaps we need to make one official Fedora-supported stack and meanwhile make it as easy as possible to install additional ruby versions + gemstacks concurrently, say, from third party repos. _______________________________________________ ruby-sig mailing list ruby-sig@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
On Fri, Sep 23, 2011 at 09:56:57AM +0200, Emanuel Rietveld wrote:
On 09/22/2011 07:52 PM, Hugh Brock wrote:
On Thu, Sep 22, 2011 at 01:37:33PM -0400, Darryl L. Pierce wrote:
On Wed, Sep 21, 2011 at 03:02:10PM -0400, Mo Morsi wrote:
This is a small part of what I mention above. One of the things we discussed was a complete separation of things like specific versions of Rails (and other gems) from version of Fedora. IOW, why should F14 be Rails 3.1? Why not let us run Fedora 17 with whatever version of Rails we choose?
Not sure if I'm following, you can always gem install any version of any gem you choose. We are talking about the single supported stack in Fedora.
I'm talking about completely separating Ruby gems from Fedora. So, for example, installing Fedora XX won't require rubygem-rails yy.xx. Insteadl, _all_ Ruby gems would be kept in a separate, optional yum repository. Then you could maintain the gems separately.
So if you're app requires Rails 2.3.11 and farkle 3.1, even though those aren't the latest, then you could install them without having to hunt down, grab and install the RPMs (and then do the same for all dependencies) manually. The one repositoryw ould have 2.3.8, 2.3.11, 3.0.0, 3.1.0, etc. and all dependent versions available.
This is probably going to give fedora packagers massive heartburn, but I think Darryl is on the right track here.
To really make this work you also need a way to install multiple stacks of gems on the same machine. So I need for example to be able to have two different Rails apps installed, each of which may depend on different and conflicting package sets, and have everything work and be happy. As horrible as this is from a support standpoint, it is the way the Ruby world works, and trying to get away from it is swimming upstream...
/me ducks large rocks
--Hugh
Perhaps we can make something like rvm (or the more recent rbenv - which does seem simpler and more robust) central to the Fedora ruby strategy. They allow you to install multiple ruby versions with multiple gem stacks concurrently, and decide on a per-application basis what ruby stack to use. It would be good it if it was easy for Fedora users to install rvm/rbenv and multiple versions of ruby and rails via rpm and have it all work out of the box.
On the other hand, it may be worth going to great lengths to ensure we have a single well-supported stack in that works with all the ruby applications we package for Fedora. Perhaps we need to make one official Fedora-supported stack and meanwhile make it as easy as possible to install additional ruby versions + gemstacks concurrently, say, from third party repos.
Yes... the problem with RVM of course is that from a production support standpoint it is a living horror:
"What Ruby interpreter are you using?"
"Hmm... let me just see if I can figure out what that environment variable was set to the last time the bug happened..."
Endorsing RVM as a winning strategy in Fedora is ultimately just enabling bad practice. "Moment-of-pleasure-for-lifetime-of-pain" type of thing.
Having said that, *trying* to get to a single well-supported stack has been so expensive and painful for us that I'm about ready to give up. I'm really not even sure it's possible. So the notion of having an "official" stack but also enabling apps to have their own stacks, as horrible as that is, may be the only sensible solution in the end.
/me contemplates rewriting everything in C...
--Hugh
On 09/23/2011 03:57 PM, Hugh Brock wrote:
On Fri, Sep 23, 2011 at 09:56:57AM +0200, Emanuel Rietveld wrote:
Perhaps we can make something like rvm (or the more recent rbenv - which does seem simpler and more robust) central to the Fedora ruby strategy. They allow you to install multiple ruby versions with multiple gem stacks concurrently, and decide on a per-application basis what ruby stack to use. It would be good it if it was easy for Fedora users to install rvm/rbenv and multiple versions of ruby and rails via rpm and have it all work out of the box.
Yes... the problem with RVM of course is that from a production support standpoint it is a living horror:
"What Ruby interpreter are you using?"
"Hmm... let me just see if I can figure out what that environment variable was set to the last time the bug happened..."
Endorsing RVM as a winning strategy in Fedora is ultimately just enabling bad practice. "Moment-of-pleasure-for-lifetime-of-pain" type of thing.
<...>
That is a fair point, but you can mitigate this a little by deploying a rvmrc or .rbenv-version file with your app instead of using environment variables. If you check that file into your revision control system, the ruby interpreter used will be consistent across deployments for a particular version of your app.
Dne 21.9.2011 17:45, Mo Morsi napsal(a):
On 09/21/2011 07:46 AM, Vít Ondruch wrote:
Dne 21.9.2011 13:43, Vít Ondruch napsal(a):
- Support of gems for MRI and JRuby. - Is it possible to share RubyGems? - Is it possible to share gems?
Its difficult since the gems themselves depend on the rubygems package which depends on MRI. Perhaps if we can break this dependency somehow this would be more feasible.
Just thought of a random idea, would the rubygems package be able to _not_ depend on a specific package, rather depend a 'ruby-interpreter' capability, which then would be provided by both the MRI and JRuby packages? Then MRI / JRuby could be swapped in / out and any gem that depends on a specific interpreter could have the MRI/JRuby dependency there instead having it in rubygems.
Granted this would make it more difficult to install both MRI and JRuby at the same time on the same system, though it may be feasible, just haven't thought this one through.
RubyGems has to be subpackage of Ruby, because they could be upgraded later separately, if needed. I am big fan of moving RubyGems out of MRI and use one RubyGems package for both MRI and JRuby and it is doable IMO.
However I am not sure how to support gems which are bit different between MRI and JRuby versions. Nokogiri would be one example. I am still missing some support in RPM for this, something like:
Requires: nokogiri-mri if mri.installed Requires: nokogiri-jruby if jruby.installed
Vit
On Thursday, September 22, 2011 09:29:37 AM Vít Ondruch wrote:
Dne 21.9.2011 17:45, Mo Morsi napsal(a):
On 09/21/2011 07:46 AM, Vít Ondruch wrote:
Dne 21.9.2011 13:43, Vít Ondruch napsal(a):
Support of gems for MRI and JRuby.
- Is it possible to share RubyGems? - Is it possible to share gems?Its difficult since the gems themselves depend on the rubygems package which depends on MRI. Perhaps if we can break this dependency somehow this would be more feasible.
Just thought of a random idea, would the rubygems package be able to _not_ depend on a specific package, rather depend a 'ruby-interpreter' capability, which then would be provided by both the MRI and JRuby packages? Then MRI / JRuby could be swapped in / out and any gem that depends on a specific interpreter could have the MRI/JRuby dependency there instead having it in rubygems.
Granted this would make it more difficult to install both MRI and JRuby at the same time on the same system, though it may be feasible, just haven't thought this one through.
RubyGems has to be subpackage of Ruby, because they could be upgraded later separately, if needed. I am big fan of moving RubyGems out of MRI and use one RubyGems package for both MRI and JRuby and it is doable IMO.
However I am not sure how to support gems which are bit different between MRI and JRuby versions. Nokogiri would be one example. I am still missing some support in RPM for this, something like:
Requires: nokogiri-mri if mri.installed Requires: nokogiri-jruby if jruby.installed
Vit
With the shift to Ruby 1.9.x.. I am preparing to get the OpenNebula packaging effort underway. had meetings with developers, I'm drawing up a wiki.
Assuming all these rubygems I'm *about* to submit work with Ruby 1.9.x I strongly suggest a compat package...
ruby-sig mailing list ruby-sig@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
On Thursday, September 22, 2011 07:48:01 PM Shawn Starr wrote:
On Thursday, September 22, 2011 09:29:37 AM Vít Ondruch wrote:
Dne 21.9.2011 17:45, Mo Morsi napsal(a):
On 09/21/2011 07:46 AM, Vít Ondruch wrote:
Dne 21.9.2011 13:43, Vít Ondruch napsal(a):
Support of gems for MRI and JRuby.
- Is it possible to share RubyGems? - Is it possible to share gems?Its difficult since the gems themselves depend on the rubygems package which depends on MRI. Perhaps if we can break this dependency somehow this would be more feasible.
Just thought of a random idea, would the rubygems package be able to _not_ depend on a specific package, rather depend a 'ruby-interpreter' capability, which then would be provided by both the MRI and JRuby packages? Then MRI / JRuby could be swapped in / out and any gem that depends on a specific interpreter could have the MRI/JRuby dependency there instead having it in rubygems.
Granted this would make it more difficult to install both MRI and JRuby at the same time on the same system, though it may be feasible, just haven't thought this one through.
RubyGems has to be subpackage of Ruby, because they could be upgraded later separately, if needed. I am big fan of moving RubyGems out of MRI and use one RubyGems package for both MRI and JRuby and it is doable IMO.
However I am not sure how to support gems which are bit different between MRI and JRuby versions. Nokogiri would be one example. I am still missing some support in RPM for this, something like:
Requires: nokogiri-mri if mri.installed Requires: nokogiri-jruby if jruby.installed
Vit
With the shift to Ruby 1.9.x.. I am preparing to get the OpenNebula packaging effort underway. had meetings with developers, I'm drawing up a wiki.
Assuming all these rubygems I'm *about* to submit work with Ruby 1.9.x I strongly suggest a compat package...
On top of that, if you're making changes. I have no choice but to wait til you settle down on your decisions. I can't package OpenNebula until this is done.
ruby-sig mailing list ruby-sig@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
ruby-sig mailing list ruby-sig@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
Dne 21.9.2011 13:46, Vít Ondruch napsal(a):
Dne 21.9.2011 13:43, Vít Ondruch napsal(a):
Hello everybody,
I'd like to bring to your attention that there was proposed by Ruby SIG meeting as part of FUDCon Milan [1]. I would like to take this meeting as change to discuss Ruby future in Fedora. Here are few point I'd like to discuss:
- Ruby 1.9.3 for F17. I have already pre-prepared feature page [2] for
this and I am working towards packaging Ruby 1.9.3. However, there are several issues including - How to correctly name and version subpackages such as RubyGems, RDoc, Rake, IRB - How to maintain updates of them late. - Directory structure.
Support of gems for MRI and JRuby. - Is it possible to share RubyGems? - Is it possible to share gems?
Support of multiple versions of gems on single installation, e.g.
Rails 2 vs Rails 3.
Refresh of Ruby Packaging Guidelines - They do not always follow best practices - They will need to be updated because of Ruby 1.9.3
gem2rpm future and possible extensions
This is list is not exhaustive, so please feel free to add few more points, which you think might be interesting to discuss.
Vit
[1] https://fedoraproject.org/wiki/FUDCon:Milan_2011 [2] https://fedoraproject.org/wiki/Features/Ruby_1.9.3 _______________________________________________ ruby-sig mailing list ruby-sig@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
I have to add few more points immediately:
Rails 3.1 for F17
Migration of RSpec to RSpec 2.x
Vit _______________________________________________ ruby-sig mailing list ruby-sig@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
Another idea:
We should get rid of the .gem in cache subfolder, which makes no sense for RPM.
Vit
Hi guys, if somebody plans to attend, could you please sing up in this thread?
I'll be there. At least to say hi!
--Marek
On 23 wrz 2011, at 14:23, Vít Ondruch wrote:
Hi guys, if somebody plans to attend, could you please sing up in this thread?
ruby-sig mailing list ruby-sig@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
Dne 21.9.2011 13:43, Vít Ondruch napsal(a):
Hello everybody,
I'd like to bring to your attention that there was proposed by Ruby SIG meeting as part of FUDCon Milan [1]. I would like to take this meeting as change to discuss Ruby future in Fedora. Here are few point I'd like to discuss:
- Ruby 1.9.3 for F17. I have already pre-prepared feature page [2] for
this and I am working towards packaging Ruby 1.9.3. However, there are several issues including - How to correctly name and version subpackages such as RubyGems, RDoc, Rake, IRB - How to maintain updates of them late. - Directory structure.
Support of gems for MRI and JRuby.
- Is it possible to share RubyGems?
- Is it possible to share gems?
Support of multiple versions of gems on single installation, e.g.
Rails 2 vs Rails 3.
Refresh of Ruby Packaging Guidelines
- They do not always follow best practices
- They will need to be updated because of Ruby 1.9.3
gem2rpm future and possible extensions
This is list is not exhaustive, so please feel free to add few more points, which you think might be interesting to discuss.
Vit
[1] https://fedoraproject.org/wiki/FUDCon:Milan_2011 [2] https://fedoraproject.org/wiki/Features/Ruby_1.9.3 _______________________________________________ ruby-sig mailing list ruby-sig@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
One additional toppic would be
* packagin of Rails, Sinatra and other Ruby applications
Vit
ruby-sig@lists.fedoraproject.org
-
Darryl L. Pierce -
Emanuel Rietveld -
Hugh O. Brock -
Jeroen van Meeuwen -
Marek Goldmann -
Mo Morsi -
Mo Morsi -
Shawn Starr -
Tejas Dinkar -
Tyler Smart -
Vít Ondruch