[scl.org] rubygems 2.2.0 in ruby scl

[Joe Rafaniello]

----- Original Message -----
> On 09/12/2014 06:41 PM, Joe Rafaniello wrote:
> > Hi all,
> >
> > Is there an easy way to tell what version of rubygems comes in the ruby
> > packaged in the software collections?
> >
> > For example:
> > https://www.softwarecollections.org/repos/rhscl/ruby200/epel-6-x86_64/
> > Can I assume since I see ruby200-rubygems-2.0.14-23.el6.x86_64.rpm, this
> > SCL provides rubygems 2.0.14?
> >
> 
> Yes, that is correct. You can confirm it by:
> 
> $ scl enable ruby200 'gem -v'
> 
> > Specifically, I want rubygems 2.2.0 since Vit Ondruch was able to get the
> > binary extension path merged upstream:
> > http://blog.rubygems.org/2013/12/26/2.2.0-released.html
> >
> > Is there a rubygems 2.2.0 package that anyone has used in the ruby200 SCL?
> >
> > Thanks,
> >
> <quote>
> No, there is not RubyGems 2.2.0 available for ruby200 collection. We
> ship only RubyGems version provided with upstream Ruby and that is
> RubyGems 2.0.14 for Ruby 2.0.
> 
> Moreover, there were more binary extension management changes in
> RubyGems 2.2.0 except the patch you are referring to, so I don't think
> they can be easily retrofitted for ruby200 scl.

Ok.
 
> However, I am wondering why you should be interested in RubyGems 2.2
> just due to this specific change?
> <\quote>

Yes, the more compatible with upstream ruby/rubygems/bundler, the easier it is for applications, especially ones that support multiple platforms.

I'd like to continue to use the SCL for the ManageIQ open source project for ruby itself for all of the benefits of packaged SCL ruby:  easy updates, silo'd ruby environment, etc.
The alternative we'd be faced with is using ruby-install/ruby-build/etc. to install the desired ruby on CentOS 6.5 and provide upgrade assistance when security issues occur.

On the other hand, we'd like to be able to upgrade our dependent gems as often as we want and let bundler handle the dependency management.
Upgrading of gems in "rpm" land can occur asynchronously outside of the "churn" of the open source project.

Because we are not compatible with upstream ruby in SCL, we are required to package many gems each time we upgrade them:
rubygem-bundler
rubygem-net-http-persistent # bundler rpm dependency
rubygem-thor # bundler rpm dependency
rubygem-thin
rubygem-daemons # thin rpm dependency
rubygem-eventmachine # thin rpm dependency
rubygem-rack # thin rpm dependency

If we add any other binary extension gems, they could also have similar problems if we're not using rubygems 2.2.0.

See: http://copr-be.cloud.fedoraproject.org/results/jrafanie/manageiq-scl/epel-6-x86_64/

Because we would be diverging upstream from downstream when we upgrade gems upstream and don't package them, we can fill this void by running CI servers with the packaged gems to ensure we detect incompatible changes the moment they land in upstream.

So, is it worthwhile to package up rubygems 2.2.0 for use in ruby 2.0 from SCL?

Is ruby 2.1.x on the roadmap?

Am I the only one to ask for help using SCL just for ruby itself?

Thanks for your help!

-- 
Joe Rafaniello