Hi,
one of the great things about Ruby webapps is the many, many options you have to deploy them. Besides choosing a web server, as a developer you also get to choose a Rails or Sinatra version, and to pick your favorite rack or Rails plugin(s).
The downside of all this is that it's a crazy duplication of work, and following all your choices, you might discover that the versions of some of your plugins conflict with rubygem-* RPM's in Fedora.
To make all this easier, it would be great if we could come up with the Grand Useful Fedora Ruby Appserver (yes, GUFRA ;). I see this whole effort consisting of two parts:
* discuss the tradeoffs at each level of the stack and come up with a recommendation for what we like (hopefully some document on the Wiki) * package whatever needs to be packaged for Fedora
The end result should make it easier for budding Ruby web developers to start with a well-tested set of tools, rather than have to go and figure all this out for themselves. And, of course, packages for all these things in F15.
To kick this off, here's what I think belongs into GUFRA:
* Ruby interpreter * frontend webserver * Ruby webserver * Rails and Sinatra * Rack plugins (which ones ?) * Rails plugins (which ones ?) * Devtools (rspec, rinari, ...)
Some thoughts on the tradeoffs:
Ruby interpreter ================
Only MRI seems practical for now, and there the big question is whether we'll make the switchover to 1.9.x in F15, and how.
Frontend webserver ==================
Frontrunners are probably httpd and nginx. Apache httpd is hte Swiss army knife, nginx is more limited, but people like how easy it is to configure.
Ruby webserver ==============
Mostly passenger vs. thin vs. unicorn. Passenger has the advantage that it can be loaded as a module into httpd, but packaging it has proven somewhat interesting.
OTOH, thin and unicorn are a nightmare to manage, since you get to babysit a good number of processes, and can't take advantage of httpd's ability to spin threads up and down depending on load.
Rails =====
For F15, the big question is whether to go with 3.0.x or the latest 2.3.x. And that mostly depends on whether people's favorite plugins are available for Rails 3.
As a sidenote, we'll also have to worry about Bundler, since that's what people are told to use for their Rails3 apps; Bundler doesn't play nice with RPM.
Plugins =======
Mostly an exercise in collecting people's favorite plugins, and making sure they are in F15, in the right version.
David
Hi,
On Sat, Oct 23, 2010 at 6:21 AM, David Lutterkort lutter@redhat.com wrote:
Hi,
Glad the discussion has started.
one of the great things about Ruby webapps is the many, many options you have to deploy them. Besides choosing a web server, as a developer you also get to choose a Rails or Sinatra version, and to pick your favorite rack or Rails plugin(s).
The downside of all this is that it's a crazy duplication of work, and following all your choices, you might discover that the versions of some of your plugins conflict with rubygem-* RPM's in Fedora.
Ruby ecosystem is famously developer friendly. But for ops, not always so. Certainly not because people are difficult. It's rather because the community is mostly concentrating on building things, not deploying.
To make all this easier, it would be great if we could come up with the Grand Useful Fedora Ruby Appserver (yes, GUFRA ;). I see this whole effort consisting of two parts:
That's a horrible name IMHO, but let's get to the important parts. :)
* discuss the tradeoffs at each level of the stack and come up with a recommendation for what we like (hopefully some document on the Wiki) * package whatever needs to be packaged for Fedora
The end result should make it easier for budding Ruby web developers to start with a well-tested set of tools, rather than have to go and figure all this out for themselves. And, of course, packages for all these things in F15.
One important thing I'd like to bring up is how this effort is going to benefit people who deploy web apps. Having a proper stack always helps a lot. Everyone's aware the hardships to endure if you plan to host Ruby webapps.
To kick this off, here's what I think belongs into GUFRA:
* Ruby interpreter * frontend webserver * Ruby webserver * Rails and Sinatra * Rack plugins (which ones ?) * Rails plugins (which ones ?) * Devtools (rspec, rinari, ...)
* Deployment tools (Eg: capistrano, etc.)
Some thoughts on the tradeoffs:
Ruby interpreter
Only MRI seems practical for now, and there the big question is whether we'll make the switchover to 1.9.x in F15, and how.
As you've said this is tricky. F14 is shipping with MRI 1.8.7 and it's not yet decided if F15 will use 1.9.x. Eventhough Rubinius 1.1.0 is out, it still doesn't seem to fully compatible with Rails 3 (which takes us to Rails version as well). Personally I don't have enough experience with rbx to comment about the performance or suitability for deployment.
Sometime ago I remember seeing (on this list) about an attempt to have parallel 1.8.x and 1.9.x stacks. If that effort has progressed we could probably benefit from it. Or should we look into having some sort of a rvm based setup?
Frontend webserver
Frontrunners are probably httpd and nginx. Apache httpd is hte Swiss army knife, nginx is more limited, but people like how easy it is to configure. From deployment point of view this is a decision or sometimes a choice. IMHO,
this however doesn't affect a developer that much. Since a Ruby webserver can serve the app, I think it'd be sufficient and simple enough unless we aim for production envs. I suggest we should.
Ruby webserver
Mostly passenger vs. thin vs. unicorn. Passenger has the advantage that it can be loaded as a module into httpd, but packaging it has proven somewhat interesting.
Phusion team promised that they'd make Passenger 3 more easy to package. I haven't been able to verify that they've kept the promise. ;) However with the final release of 3.0 we have another entry to this list; Passenger Standalone [1]. Given the fact it's uses an Nginx core it might be worth a look for packaging.
OTOH, thin and unicorn are a nightmare to manage, since you get to babysit a good number of processes, and can't take advantage of httpd's ability to spin threads up and down depending on load.
Rails
For F15, the big question is whether to go with 3.0.x or the latest 2.3.x. And that mostly depends on whether people's favorite plugins are available for Rails 3.
It's still too early to talk about adotion. But give that F15 has more than 6 months for release, we could look into the inclusion of Rails 3.
As a sidenote, we'll also have to worry about Bundler, since that's what people are told to use for their Rails3 apps; Bundler doesn't play nice with RPM.
Unfortunately, there's nothing I can suggest to avoid this case. It can cause headaches.
Plugins
Mostly an exercise in collecting people's favorite plugins, and making sure they are in F15, in the right version.
Here's a wild thought (not original, came up in Twitter discussions). Why don't we try to work with rubygems.org to generate (or at least get some level of integration to) native packages; in our case RPMs? It's bit ambitious. But it's certainly worth looking into. This could eliminate the need to use *.gem instead of replying on rubygem-*.rpm
David
One more note regarding the above mentions tools. Since some of them have never been packaged for Fedora before (Eg: passnger standalone), among other things it'll be necessary to make sure they play nice with SELinux.
I'm not officially a package maintainer yet. But I'd love to become one and take part in the work ahead.
[1] http://www.modrails.com/documentation/Users%20guide%20Standalone.html
On 10/22/2010 09:56 PM, Gaveen Prabhasara wrote:
<snip> > Ruby webserver > ============== > > Mostly passenger vs. thin vs. unicorn. Passenger has the advantage that > it can be loaded as a module into httpd, but packaging it has proven > somewhat interesting. Phusion team promised that they'd make Passenger 3 more easy to package. I haven't been able to verify that they've kept the promise. ;) However with the final release of 3.0 we have another entry to this list; Passenger Standalone [1]. Given the fact it's uses an Nginx core it might be worth a look for packaging.
Passenger can't be included in Fedora as is due to legal reasons. If we want to ship it, we will have to hack it to remove some vendorized components and call it something else ("Phusion Passenger" is trademarked, perhaps "modrails" would work though)
https://bugzilla.redhat.com/show_bug.cgi?id=470696
Plugins
Mostly an exercise in collecting people's favorite plugins, and making sure they are in F15, in the right version.
Here's a wild thought (not original, came up in Twitter discussions). Why don't we try to work with rubygems.org to generate (or at least get some level of integration to) native packages; in our case RPMs? It's bit ambitious. But it's certainly worth looking into. This could eliminate the need to use *.gem instead of replying on rubygem-*.rpm
Might be somewhat different that what your talking about but I actually wrote a tool to do something like this a while back. It sits inbetween the gemcutter webhook api and rpmbuild, constructing rpms and yum repos when gems are pushed. I haven't touched it in a while, but might be worth reviving.
http://github.com/movitto/polisher http://github.com/movitto/polisher-scripts
-Mo
Mohammed Morsi wrote:
On 10/22/2010 09:56 PM, Gaveen Prabhasara wrote:
<snip>
Ruby webserver
Mostly passenger vs. thin vs. unicorn. Passenger has the advantage that it can be loaded as a module into httpd, but packaging it has proven somewhat interesting.
Phusion team promised that they'd make Passenger 3 more easy to package. I haven't been able to verify that they've kept the promise. ;) However with the final release of 3.0 we have another entry to this list; Passenger Standalone [1]. Given the fact it's uses an Nginx core it might be worth a look for packaging.
Passenger can't be included in Fedora as is due to legal reasons. If we want to ship it, we will have to hack it to remove some vendorized components and call it something else ("Phusion Passenger" is trademarked, perhaps "modrails" would work though)
Hold on, because these are directly dependent on one another;
- If we hack boost out of passenger, we may not call it Phusion Passenger any longer.
Should we accept the fact the only hacking to be done should probably happen upstream, and continue to consume the downstream as such then hey, we don't have to rename it.
My goal is not even so much to get passenger to be excellent, my goal is to prevent thousands of downstream consumers deploying their own builds and not having an update stream (not to mention crappy compile options and all sorts of other crap you have with one-off unique builds), and for Fedora to be where all that momentum comes together.
If nothing else, I'll continue to distribute rubygem-passenger as part of Yet Another add-on repository, see how people like that.
Kind regards,
Jeroen van Meeuwen -kanarip
Ruby webserver
==============
Mostly passenger vs. thin vs. unicorn. Passenger has the advantage that it can be loaded as a module into httpd, but packaging it has proven somewhat interesting.
what about mongrel ?
afaik packaging passenger has issues which are not technical, cant remember exactly what it is (legal maybe).
OTOH, thin and unicorn are a nightmare to manage, since you get to babysit a good number of processes, and can't take advantage of httpd's ability to spin threads up and down depending on load.
Usually what im doing is place a proxy to do that, haproxy. Apache > haproxy > mongrel_cluster
But yes, there's no ability to spin threads on demand.
------------------------ Guillermo ------------------------ http://www.neotechgw.com http://gomix.fedora-ve.org
2010/10/23 Guillermo Gómez guillermo.gomez@gmail.com:
Ruby webserver
==============
Mostly passenger vs. thin vs. unicorn. Passenger has the advantage that it can be loaded as a module into httpd, but packaging it has proven somewhat interesting.
what about mongrel ?
And there's Mongrel2 [1] also.
Guillermo
If people really want to see Fedora as a first class ruby platform, I can only suggest that every question about what interpreter and gems be answered by being the first distro to be come by default as a system wide rvm based setup. rvm would answer about every discussion around "how to do it". I've been using rvm on my systems for quite some time and have had little to no problem. With a system wide rvm setup, we could effectively drop support for a lot of gem rpms and focus on making the upstream ruby a lot better.
It would certainly add to some confusion, and out of the box we'd want to deploy some basic tools and perhaps 1.8.7, but I really think it would mean a lot for ruby (a comfy path away from 1.8.x) and fedora in general to use a system-wide rvm approach.
Objections?
On Oct 23, 2010 11:12 AM, "Gaveen Prabhasara" gaveen@owain.org wrote:
2010/10/23 Guillermo Gómez guillermo.gomez@gmail.com:
Ruby webserver
==============
Mostly passenger vs. thin vs. unicorn. Passenger has the a...
And there's Mongrel2 [1] also.
Guillermo
[1] http://mongrel2.org/ -- Gaveen Prabhasara
_______________________________________________ ruby-sig mailing list ruby-sig@lists.fedoraproject.o...
On Tue, Oct 26, 2010 at 6:11 AM, Mike Danko mike@l4m3.com wrote:
If people really want to see Fedora as a first class ruby platform, I can only suggest that every question about what interpreter and gems be answered by being the first distro to be come by default as a system wide rvm based setup. rvm would answer about every discussion around "how to do it". I've been using rvm on my systems for quite some time and have had little to no problem. With a system wide rvm setup, we could effectively drop support for a lot of gem rpms and focus on making the upstream ruby a lot better.
I only started using rvm recently, and therefore can't comment on how primetime ready it is. But given all the benefits it's say it's definitely worth checking.
If we can have a stable and usable system-wide rvm (and iron-out some minor quirks for certain popular gems) or similar setup, it could be a good stride towards making Ruby a first-class citizen in Fedora and making Fedora a very likeable distro choice for Ruby community.
It would certainly add to some confusion, and out of the box we'd want to deploy some basic tools and perhaps 1.8.7, but I really think it would mean a lot for ruby (a comfy path away from 1.8.x) and fedora in general to use a system-wide rvm approach.
Objections?
I'm not saying that it has to be rvm and only rvm, but the idea sounds neat. There would be some packaging changes necessary if we are to achieve a rvm or any other good multi-ruby env.
+1 from me for the idea of system-wide rvm/multi-ruby env
On Oct 23, 2010 11:12 AM, "Gaveen Prabhasara" gaveen@owain.org wrote:
2010/10/23 Guillermo Gómez guillermo.gomez@gmail.com:
Ruby webserver
==============
Mostly passenger vs. thin vs. unicorn. Passenger has the a...
And there's Mongrel2 [1] also.
Guillermo
[1] http://mongrel2.org/
Gaveen Prabhasara
El 26/10/10 03:41, Gaveen Prabhasara escribió:
I only started using rvm recently, and therefore can't comment on how primetime ready it is. But given all the benefits it's say it's definitely worth checking.
I still dont use it but agree its worth checking...
I'm not saying that it has to be rvm and only rvm, but the idea sounds neat. There would be some packaging changes necessary if we are to achieve a rvm or any other good multi-ruby env.
I really dont feel comfortable with fedora multi-envs in general. Fedora being Fedora, im not sure we should have it or not. Keeping and "old" environment (compat) is more like a enterprise level requirement and i dont know we have enough human resources in ruby-sig/pacakgers to deal with it.
I already have a friend who's complaining about F14 not pushing the envelope and just including sw updates, what he said, "not fun at all".
I feel the Fedora way pushes us to move to 1.9 for F15. If we can cope with a multi-envs, fine, but for me is a low prio.
+1 from me for the idea of system-wide rvm/multi-ruby env
0 (still in neutral)
Guillermo
Hi,
I'm not a heavy ruby user (I don't use it on my F13 workstation, I use it on CentOS for puppet) but my view is that, as standard, Fedora should ship a single ruby version - preferably a recent one. I would imagine that most ruby end-users simply don't need multiple versions
However, it should be possible to install rvm if required, and the rvm packaging should either work in parallel with the system ruby, or should obsolete it and work seamlessly.
R,
On Thu, Oct 28, 2010 at 8:33 AM, Robin Bowes robin-lists@robinbowes.com wrote:
Hi,
I'm not a heavy ruby user (I don't use it on my F13 workstation, I use it on CentOS for puppet) but my view is that, as standard, Fedora should ship a single ruby version - preferably a recent one. I would imagine that most ruby end-users simply don't need multiple versions
However, it should be possible to install rvm if required, and the rvm packaging should either work in parallel with the system ruby, or should obsolete it and work seamlessly.
I'd say there is quite a different audience between ruby user (puppet, redmine or something) vs a ruby developer.
Ruby developers like and use RVM, and today, normally use a mac. Making Fedora/EPEL/RHEL a better platform for ruby long-term means appealing to the development crowd. The user base for simple ruby application is already there. Some of the things done to appeal to developers are basically unholy and ungood in general. Sticking libs in vendor is a bad but continues to happen on nearly every major ruby project. (and don't get me started on bundler).
Yet, Somehow we need to appeal to ruby developers, at least as a platform for production deployments. This would probably be done by having things like ruby application servers, and deployment tools available. There are also some cases where we might want to maintain parallel gem installations when both branches are still being maintained (rails 2 vs 3, rspec 1.3 vs 2.0, etc). This would appeal to the ruby developer more.
If you look at the rails rumble from 2 weeks ago, less than 2% of systems used were Fedora/CentOS. That's quite sad. Most used Ubuntu, and I am guessing just installed ruby gems and built the rest from source, as Ubuntu's ruby stack IMHO, is in worse shape than that of Fedora.
The other problem with using 'latest' is that ruby 1.9 really isn't in use for many big application yet. I mean, it will be, but I don't know if Amarok works with it yet. I know puppet/facter still have bugs open for 1.9 compatibility. Going to 1.9 and obsoleting 1.8 is a pretty big step.
As some take-aways: * We should be working to get more and more gems into the Fedora world, and this should include EPEL as that's where most production applications get targeted for deployment. * The ruby 1.9 parallel installation discussion should continue. RVM might be answer. * Somehow we need to get passenger into fold. Right now I think it's a significant drawback that I can't use ruby with apache without adding additional third-party repos that sometimes replace other ruby portions of the stack. * Market/advertise and discuss any big-time ruby applications utilizing Centos/Fedora/RHEL as the backing platform.
stahnma
On 28/10/10 15:43, Michael Stahnke wrote:
I'd say there is quite a different audience between ruby user (puppet, redmine or something) vs a ruby developer.
Yes, I would agree. The point I was trying to make is that the average ruby user just wants to be able to do "yum install app-that-uses-ruby" and for it to work. They are not bothered about the same issues that devs are. Therefore, I think Fedora should default to this (what I perceive to be) most common use-case, but also make it easy to use rvm as well/instead.
If you look at the rails rumble from 2 weeks ago, less than 2% of systems used were Fedora/CentOS. That's quite sad. Most used Ubuntu, and I am guessing just installed ruby gems and built the rest from source, as Ubuntu's ruby stack IMHO, is in worse shape than that of Fedora.
I would imagine that's largely due to Ubuntu's percevied "coolness" and the fact that CentOS/RHEL/Fedora has a very old Ruby version. Indeed, some projects won't support ruby 1.8.6 making it difficult to use them on Fedora/CentOS. For example, capistrano. This statement from the maintainer on ruby 1.8.6:
"it is effectively obsolete; and given it's age, and the catalog of problems I certainly won't go out of my way to support it here."
R.
On 10/28/2010 11:26 AM, Robin Bowes wrote:
On 28/10/10 15:43, Michael Stahnke wrote:
I'd say there is quite a different audience between ruby user (puppet, redmine or something) vs a ruby developer.
Yes, I would agree. The point I was trying to make is that the average ruby user just wants to be able to do "yum install app-that-uses-ruby" and for it to work. They are not bothered about the same issues that devs are. Therefore, I think Fedora should default to this (what I perceive to be) most common use-case, but also make it easy to use rvm as well/instead.
Well this is currently the case with Fedora. Any developer can install rubygems and rubygem-rvm and configuring their system using rvm from there on out. I would think anything which we might do from here on wouldn't affect this, as developers could always fallback to using gem / rvm manually.
If you look at the rails rumble from 2 weeks ago, less than 2% of systems used were Fedora/CentOS. That's quite sad. Most used Ubuntu, and I am guessing just installed ruby gems and built the rest from source, as Ubuntu's ruby stack IMHO, is in worse shape than that of Fedora.
I would imagine that's largely due to Ubuntu's percevied "coolness" and the fact that CentOS/RHEL/Fedora has a very old Ruby version. Indeed, some projects won't support ruby 1.8.6 making it difficult to use them on Fedora/CentOS. For example, capistrano. This statement from the maintainer on ruby 1.8.6:
"it is effectively obsolete; and given it's age, and the catalog of problems I certainly won't go out of my way to support it here."
R.
Agreed, we were on 1.8.6 for too long. F14 (shipping next tuesday) will have 1.8.7 and I'll start to looking into resuming what needs to be done for Ruby 1.9 (parallel or not) in the near future.
-Mo
El 28/10/10 10:13, Michael Stahnke escribió:
I would imagine that most ruby end-users simply don't need multiple versions
They should not even bother or know there are multiples versions.
However, it should be possible to install rvm if required, and the rvm packaging should either work in parallel with the system ruby, or should obsolete it and work seamlessly.
Actual Fedora Ruby Developers probably just do
# yum instal rubygems
and then
# gem instal mygem
Why, simple, gem can manage multiple versions withouth any hazzle, we know. Developers usually can deal with it, and we should lead them on the right path, yes, they(we) do commit unholly sins.
Then when moving to a production stage, would verify/manage/decide to use Fedora (OS) provided rubygems or not. Maybe they are not available, and that's where rpm-packaging-gems comes to play a major role.
If we package most of the usefull, latest and stable gems, then Fedora would be an appealing platform for ruby developers. Maybe at somepoint they could just start developing not using gems from source and then push back the pressure to upstream gems/apps developers to keepup and update/upgrade for no regresions or compat issues. Avoid "specific" version to run, its not a feature, its a panfull mess to manage multiples gem versions.
I'd say there is quite a different audience between ruby user (puppet, redmine or something) vs a ruby developer.
Im still missing redmine not being part of fedora...
Yet, Somehow we need to appeal to ruby developers, at least as a platform for production deployments. This would probably be done by having things like ruby application servers, and deployment tools available.
+1
There are also some cases where we might want to maintain parallel gem installations when both branches are still being maintained (rails 2 vs 3, rspec 1.3 vs 2.0, etc).
This case takes me back to the Apache 1.3 vs Apache 2, as far as i recall, Fedora never shipped Apache 1.3, is not in our nature to that kind of things. Someone please correct me if im wrong. We should focus on pushing upstreams, using the latests, package them, and move on. Maitained is no reason enough for Fedora for shipping it, but my guess is no sin either to do it.
If you look at the rails rumble from 2 weeks ago, less than 2% of systems used were Fedora/CentOS. That's quite sad. Most used Ubuntu, and I am guessing just installed ruby gems and built the rest from source, as Ubuntu's ruby stack IMHO, is in worse shape than that of Fedora.
I thinks this just proove that its not related to the ruby stack state in Fedora. But yes, still sad.
The other problem with using 'latest' is that ruby 1.9 really isn't in use for many big application yet. I mean, it will be, but I don't know if Amarok works with it yet. I know puppet/facter still have bugs open for 1.9 compatibility. Going to 1.9 and obsoleting 1.8 is a pretty big step.
We should track that, and then take a decision early enough for f15. We have the opportunity to switch from 1.8 to 1.9 kind of easily since there are NOT hundreds/thousands of apps being used in Fedora.
In fact we should promote and help this transition for developers. We should build a plan ;) Im not yet at 1.9 level, but my guess is, 1.9 is better, then why keep my apps at 1.8? As a developer i should move on and release under 1.9 umbrella. Being a 1.8 developer is becoming history and we should face the fact in the Fedora way.
As some take-aways:
- We should be working to get more and more gems into the Fedora
world, and this should include EPEL as that's where most production applications get targeted for deployment.
+1
- The ruby 1.9 parallel installation discussion should continue. RVM
might be answer.
+1
- Market/advertise and discuss any big-time ruby applications
utilizing Centos/Fedora/RHEL as the backing platform.
Hey, did i mention that we should gather at Tempe and do something ?
"Maybe" i wil be doing ruby coding dojo mentored by toshio..
Guillermo ------------------------ http://www.neotechgw.com http://gomix.fedora-ve.org
On 10/26/2010 09:59 AM, Guillermo Gómez wrote:
El 26/10/10 03:41, Gaveen Prabhasara escribió:
I only started using rvm recently, and therefore can't comment on how primetime ready it is. But given all the benefits it's say it's definitely worth checking.
I still dont use it but agree its worth checking...
The problem with rvm in this context is that its a package management system in itself. Sure gem also provides package management and deployment capabilities, but we aren't using those features in Fedora, rather we are just making use of the package format.
It is generally not the best practice to start combing package management systems on a system wide basis. For individual users and developers its acceptable, but for many admins you just can't do that, you need a single tested / proven software stack, installed / configured / deployed via one standard means. Without this, Ruby on Fedora will not be acceptable in certain deployment scenarios.
I'm not saying that it has to be rvm and only rvm, but the idea sounds neat. There would be some packaging changes necessary if we are to achieve a rvm or any other good multi-ruby env.
I really dont feel comfortable with fedora multi-envs in general. Fedora being Fedora, im not sure we should have it or not. Keeping and "old" environment (compat) is more like a enterprise level requirement and i dont know we have enough human resources in ruby-sig/pacakgers to deal with it.
I already have a friend who's complaining about F14 not pushing the envelope and just including sw updates, what he said, "not fun at all".
On the other hand, I'm sure there are users who would complain if things change too much without consideration. I agree that we should try to keep up with upstream as much as possible, so as not to stagnate, and in the long run I don't think this is going to be a major problem as projects mature and stabilize, but for the time being we need to find that fine line between these rapidly changes and stability / backwards compatibility.
I feel the Fedora way pushes us to move to 1.9 for F15. If we can cope with a multi-envs, fine, but for me is a low prio.
I don't think its as big of a deal for Ruby itself, as we can ship both and phase 1.8 out over time. Also there are many gems which have reached stable points and shouldn't cause a problem here on out. Its the gems (such as rails) that have seen alot of api instability recently that is cause for some concern.
So here is an idea I just came up with. gem and rpm are both package formats, so we have gem2rpm to perform the conversion from the dev community format to the Fedora system format. If rvm and yum are both package manement systems, and the dev community perfers rvm while Fedora prefers yum, would a tool such as rvm2yum make sense? This wouldn't solve the problem of having one standard Ruby/Fedora deployment scenario which I still think would be necessary, but if we combine it with something like Copr, we could also support deploying custom ruby software stacks for various purposes, all integrated with Fedora.
https://fedoraproject.org/wiki/Category:Copr
Haven't spent time considering all the ramifications, and as suggested we would still need to come up with an 'official' stack to ship with Fedora itself. Any thoughts?
-Mo
On Fri, Oct 29, 2010 at 1:47 AM, Mohammed Morsi mmorsi@redhat.com wrote:
So here is an idea I just came up with. gem and rpm are both package formats, so we have gem2rpm to perform the conversion from the dev community format to the Fedora system format. If rvm and yum are both package manement systems, and the dev community perfers rvm while Fedora prefers yum, would a tool such as rvm2yum make sense? This wouldn't solve the problem of having one standard Ruby/Fedora deployment scenario which I still think would be necessary, but if we combine it with something like Copr, we could also support deploying custom ruby software stacks for various purposes, all integrated with Fedora.
Supporting custom stacks while having a standard/official stack is a nice idea. And depending on how it's done it could be a better solid approach. With the above suggestions and polisher, I think it could certainly have a good appeal.
I'd love Fedora to be the foremost Ruby dev/deploy platform and the same time I belong also to the crowd who wants Fedora boxes to be managed with Puppet (or Chef, etc.). So while I would want to deploy multiple stacks, I'd certainly want to have a standard stack in Fedora.
Haven't spent time considering all the ramifications, and as suggested we would still need to come up with an 'official' stack to ship with Fedora itself. Any thoughts?
Great discussion. Which also reminds us of the state of Ruby in distros. I was a little ambiguous in my last mails regarding couple of things. I too, do agree that we should have an official stack. My suggestions is that we look towards 1.9.x for F15.
MRI development is concentrated on 1.9.x and people seems to be gradually moving from 1.8.x towards that, and most of the popular projects support 1.9.x already.
-Mo
ruby-sig@lists.fedoraproject.org
-
"Guillermo Gómez S." -
David Lutterkort -
Gaveen Prabhasara -
Jeroen van Meeuwen -
Michael Stahnke -
Mike Danko -
Mo Morsi -
Robin Bowes