Hey all,
I've been working lately in ruby packages for 1.8, 1.9,REE and Rubinius that install in parallel and a ruby-base package that basically pulls upstream ruby package (standard fedora/RHEL ruby) and provides a script to switch between different ruby implementations when available.
I've also been researching the fedora project wiki but haven't found anything related to something like this in the roadmap.
So, what do you guys think about this? is this totally insane?
There's definitely the need out there to have different ruby implementations available (lots of ppl using RVM for this reason) or at least give the user the choice to install any of them without scarifying the benefits that native packages provides.
I'd love to hear what do you guys think about this stuff and I'd love to contribute with some sort of proposal if you guys think we can waste some cycles investigating this path.
Rgds.
On 07/28/11 - 12:09:58PM, Sergio Rubio wrote:
Hey all,
I've been working lately in ruby packages for 1.8, 1.9,REE and Rubinius that install in parallel and a ruby-base package that basically pulls upstream ruby package (standard fedora/RHEL ruby) and provides a script to switch between different ruby implementations when available.
I've also been researching the fedora project wiki but haven't found anything related to something like this in the roadmap.
So, what do you guys think about this? is this totally insane?
There's definitely the need out there to have different ruby implementations available (lots of ppl using RVM for this reason) or at least give the user the choice to install any of them without scarifying the benefits that native packages provides.
I'd love to hear what do you guys think about this stuff and I'd love to contribute with some sort of proposal if you guys think we can waste some cycles investigating this path.
My personal view is that per Fedora release cycle, we should have a single stack of ruby + rubygems that is "known good". For example, on Fedora 16 we are going to be shipping ruby 1.8.7, plus rubygems for rails 3.0.9, and all of the dependencies for that. Everything there should be tested together and at verified to work together.
In addition, we also provide rvm for those who want to use alternatives to the "known good" stack; that will allow them to mix and match gems that come from the packaging, along with gems that they get from rubygems.org.
Finally, we should think about packaging ruby 1.9 as an alternative to ruby 1.8, possibly calling the package ruby19 and using alternatives to switch between the two (like python and python3).
If we did all of that, would that fit your use case? If not, I'm not sure what you are proposing, could you explain further?
On Thu, Jul 28, 2011 at 12:19 PM, Chris Lalancette clalance@redhat.com wrote:
On 07/28/11 - 12:09:58PM, Sergio Rubio wrote:
My personal view is that per Fedora release cycle, we should have a single stack of ruby + rubygems that is "known good". For example, on Fedora 16 we are going to be shipping ruby 1.8.7, plus rubygems for rails 3.0.9, and all of the dependencies for that. Everything there should be tested together and at verified to work together.
Yeah, understand. Makes a lot of sense from a QA perspective. However the proposal does not change that IMO. I mean, you can still have ruby-base ( fictitious package ) pulling the default and well tested 1.8 stack.
The trick here is that Fedora could provide an 'alternatives' mechanism to switch between ruby implementations easily (i.e. 'ruby-switch system' or 'ruby-switch 19', etc), since they can be installed in parallel. Some sort of RVM but using packaged ruby implementations.
In addition, we also provide rvm for those who want to use alternatives to the "known good" stack; that will allow them to mix and match gems that come from the packaging, along with gems that they get from rubygems.org.
Sure, RVM is great and flexible. However building a ruby implementation when installing is very expensive, so it's far from ideal in some scenarios.
Finally, we should think about packaging ruby 1.9 as an alternative to ruby 1.8, possibly calling the package ruby19 and using alternatives to switch between the two (like python and python3).
If we did all of that, would that fit your use case? If not, I'm not sure what you are proposing, could you explain further?
Yeah, I've been doing exactly that (https://github.com/frameos/ruby19-rpm) with some other ruby implementations also. However it's not enough I believe, we need to go a step further.
i.e. If I have a Chef stack installed, I'd love to be able to switch from ruby18 to ruby19 or ruby-ee and be able to use Chef again without having to use gem19 install chef (for example). In order to achieve that, we need at least (please, correct me if I'm missing stuff):
1. /usr/bin/ruby needs to point to 1.9 ruby (using something like ruby-switch) 2. Native gems need to be rebuilt? 3. Existing pure ruby gems need to be available to 1.9
2. and 3. are kind of complex to achieve (but achievable I believe) so the can be left out of the equation initially. Having a ruby implementation 'switch' would be just great to get started.
Does it make sense?
Rgds.
-- Chris Lalancette _______________________________________________ ruby-sig mailing list ruby-sig@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
Hello Sergio,
Any proposal like this just over-complicate things. You are looking on Fedora from upstream developer point of view while our users just wants to use software. So at the end, if your application supports Ruby which are shipped with Fedora, then it is enough for you and for end user. There is important role which is plays package maintainer, specifically he/she has to assure that a package is compatible with distribution and possibly to work on that with upstream.
So tell me why you need every possible version of Ruby available in Fedora?
Tell me why I, as an end user, should care if you application is running with Ruby 1.8, Ruby 1.9, REE, Rubinius or JRuby? Tell me why I, as a Fedora package, should care about my gem for more Ruby implementations/versions?
Neither of that make sense to me.
Vit
Dne 28.7.2011 12:09, Sergio Rubio napsal(a):
Hey all,
I've been working lately in ruby packages for 1.8, 1.9,REE and Rubinius that install in parallel and a ruby-base package that basically pulls upstream ruby package (standard fedora/RHEL ruby) and provides a script to switch between different ruby implementations when available.
I've also been researching the fedora project wiki but haven't found anything related to something like this in the roadmap.
So, what do you guys think about this? is this totally insane?
There's definitely the need out there to have different ruby implementations available (lots of ppl using RVM for this reason) or at least give the user the choice to install any of them without scarifying the benefits that native packages provides.
I'd love to hear what do you guys think about this stuff and I'd love to contribute with some sort of proposal if you guys think we can waste some cycles investigating this path.
Rgds. _______________________________________________ ruby-sig mailing list ruby-sig@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
On Thu, Jul 28, 2011 at 1:35 PM, Vít Ondruch vondruch@redhat.com wrote:
Hello Sergio,
Any proposal like this just over-complicate things. You are looking on Fedora from upstream developer point of view while our users just wants to use software. So at the end, if your application supports Ruby which are shipped with Fedora, then it is enough for you and for end user. There is important role which is plays package maintainer, specifically he/she has to assure that a package is compatible with distribution and possibly to work on that with upstream.
So tell me why you need every possible version of Ruby available in Fedora?
Tell me why I, as an end user, should care if you application is running with Ruby 1.8, Ruby 1.9, REE, Rubinius or JRuby? Tell me why I, as a Fedora package, should care about my gem for more Ruby implementations/versions?
Yes, it's a good point, and probable makes a lot of sense from a Fedora packager point of view.
It's also true that a lot of ops and devels out there (users, in any case) want to use Fedora/RHEL for their stacks and want to be able to use the ruby impl they prefer (cause provided impl is old, boring, or whatever reason) without having to resort to compiling stuff and manually tweaking the system.
Neither of that make sense to me.
It's all about adding flexibility and upstream maintained ruby packages to Fedora while trying to hide some of the complexity and boring stuff that (some) users have to deal with when switching ruby implementations.
Rgds.
Vit
Dne 28.7.2011 12:09, Sergio Rubio napsal(a):
Hey all,
I've been working lately in ruby packages for 1.8, 1.9,REE and Rubinius that install in parallel and a ruby-base package that basically pulls upstream ruby package (standard fedora/RHEL ruby) and provides a script to switch between different ruby implementations when available.
I've also been researching the fedora project wiki but haven't found anything related to something like this in the roadmap.
So, what do you guys think about this? is this totally insane?
There's definitely the need out there to have different ruby implementations available (lots of ppl using RVM for this reason) or at least give the user the choice to install any of them without scarifying the benefits that native packages provides.
I'd love to hear what do you guys think about this stuff and I'd love to contribute with some sort of proposal if you guys think we can waste some cycles investigating this path.
Rgds. _______________________________________________ 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
Tell me why I, as an end user, should care if you application is running with Ruby 1.8, Ruby 1.9, REE, Rubinius or JRuby? Tell me why I, as a Fedora package, should care about my gem for more Ruby implementations/versions?
I had to say that from what i know (which is not much), jruby is really special case here (im just reading about it).
Basically jruby is not just another ruby implementation is something really different and powerfull, but hey, im just starting to read about it and correct me if im wrong (does jruby plays well with our java vm?).
You can do things with jruby u simply cant with just ruby (any implementation).
I would vote against complicating "things" in fedora, BUT, i think we could be missing something really importante here, jruby apps would just not work in our boxes whitouth tweaking.
¿Shouldnt we just choose to switch to a better ruby interpreter and keep our landscape simple or use parallel stacks and tools to complicate things and be more flexible?
Better of course meanss a whole debate.
2011/7/29 Guillermo Gómez guillermo.gomez@gmail.com:
Tell me why I, as an end user, should care if you application is running with Ruby 1.8, Ruby 1.9, REE, Rubinius or JRuby? Tell me why I, as a Fedora package, should care about my gem for more Ruby implementations/versions?
I had to say that from what i know (which is not much), jruby is really special case here (im just reading about it).
Basically jruby is not just another ruby implementation is something really different and powerfull, but hey, im just starting to read about it and correct me if im wrong (does jruby plays well with our java vm?).
That's the case with every ruby implementation out there. All of them have special features with their own benefits and drawbacks (performance, persistence, concurrency, bridges to other langs and frameworks, etc).
Having sane defaults and supporting one ruby implementation makes a lot of sense. Discarding other ruby implementation cause user or the packager doesn't care does not IMO.
On Fri, Jul 29, 2011 at 8:37 AM, Sergio Rubio rubiojr@frameos.org wrote:
2011/7/29 Guillermo Gómez guillermo.gomez@gmail.com:
Tell me why I, as an end user, should care if you application is running with Ruby 1.8, Ruby 1.9, REE, Rubinius or JRuby? Tell me why I, as a Fedora package, should care about my gem for more Ruby implementations/versions?
I had to say that from what i know (which is not much), jruby is really special case here (im just reading about it).
Basically jruby is not just another ruby implementation is something really different and powerfull, but hey, im just starting to read about it and correct me if im wrong (does jruby plays well with our java vm?).
That's the case with every ruby implementation out there. All of them have special features with their own benefits and drawbacks (performance, persistence, concurrency, bridges to other langs and frameworks, etc).
Having sane defaults and supporting one ruby implementation makes a lot of sense. Discarding other ruby implementation cause user or the packager doesn't care does not IMO.
Yes, we should (we must) have one sane default if we want to keep it simple (packaging/installing/using), but who's saying that the actual default is the best sane default to deliver in average? Who and how it is decided?
Point is that jruby apps wont work in our actual ruby default stack without tweaking, the other way around would just work as usual (theoretically). So in this case switching to jruby presents a good case (im not a big defender here of jruby just yet, im just presenting the case and giving reasons to why we could consider other defaults or why to go and further make our stack a more complex setup).
Other implementatios afaik does not present this user case.
Yes, we should (we must) have one sane default if we want to keep it simple (packaging/installing/using), but who's saying that the actual default is the best sane default to deliver in average? Who and how it is decided?
It would seem to me that the standard ruby should be the default Ruby installation. From here it is just a question of what version? What do we have that still depends on Ruby 1.8? I think puppet had problems with 1.9 for a while (and maybe it still does)... But what else? What is preventing us from (or a better question may be "why haven't we" ) shipping 1.9 in parallel with 1.8? We've shipped python3 as an option for a couple of Fedora releases now, it would seem to me that we could/should be doing the same with Ruby.
Even Debian got this out the door before us, as Squeeze has ruby1.8 and ruby 1.9 both available in their standard repos. So this isn't unprecedented or infeasible.
ruby-sig@lists.fedoraproject.org
-
"Guillermo Gómez S." -
Chad Feller -
Chris Lalancette -
Sergio Rubio -
Vít Ondruch