Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

Support for multiple RubyGems version #68

Closed
michaelklishin opened this Issue · 21 comments

5 participants

@michaelklishin

It would be very handy to have support for multiple RubyGems version. Here is a ticket that explains why. I talked to @svenfuchs in #travis on Freenode and he suggests that I file this issue.

One possible solution is to have separate gemsets like 1.8.7_rubygems13, 1.8.7_rubygems17, 1.8.7_rubygems18, 1.9.2_rubygems13 and so on.

@michaelklishin

After working on actual infrastructure for a while I can say this feature is very advanced and will probably require modifications to RVM. Not worth it.

@svenfuchs
Owner

+1 for now

@rakaur

Is there no way to specify RubyGems version? The rbi and jruby installs are still using 1.3.7 and we're on 1.8.10. The later ones have depreciated much of the older API and so none of my apps will build on travis' idea of rbx or jruby even though it's only because of old RubyGems.

@michaelklishin

@rakaur there is no. We use rubygems version that RVM provides and there are no plans to change that. I doubt that Rubinius and JRuby are using 1.3.7 though, RVM is on 1.5 or 1.6 as far as I remember. Same goes for bundled rubygems version JRuby has.

@michaelklishin

@rakaur here are versions of RubyGems we have:

vagrant@lucid32:~$ ruby --version && gem --version
ruby 1.8.7 (2011-06-30 patchlevel 352) [i686-linux]
1.8.10
vagrant@lucid32:~$ rvm use 1.9.2
Using /home/vagrant/.rvm/gems/ruby-1.9.2-p290
vagrant@lucid32:~$ ruby --version && gem --version
ruby 1.9.2p290 (2011-07-09 revision 32553) [i686-linux]
1.8.10
vagrant@lucid32:~$ rvm use 1.9.3
Using /home/vagrant/.rvm/gems/ruby-1.9.3-preview1
vagrant@lucid32:~$ ruby --version && gem --version
ruby 1.9.3dev (2011-07-31 revision 32789) [i686-linux]
1.8.10
vagrant@lucid32:~$ rvm use jruby
Using /home/vagrant/.rvm/gems/jruby-1.6.4
vagrant@lucid32:~$ ruby --version && gem --version
jruby 1.6.4 (ruby-1.8.7-p330) (2011-08-23 17ea768) (OpenJDK Server VM 1.6.0_20) [linux-i386-java]
1.5.1
vagrant@lucid32:~$ rvm use rbx-2.0
Using /home/vagrant/.rvm/gems/rbx-2.0.0pre
vagrant@lucid32:~$ ruby --version && gem --version
rubinius 2.0.0dev (1.8.7 4241a27d yyyy-mm-dd JI) [i686-pc-linux-gnu]
1.5.2

You can try installing another version (using RVM) in your before_script (we even provide passwordless sudo, VMs are snapshotted and rolled back between builds) but this question was brought up only a couple of times since this ticket was closed. 1.5+ seems to satisfy vast majority of projects.

@rakaur

1.5 does not have Gem::Specification#find_all_by_name. The API RubyGems presents for resolving dependencies has changed drastically from 1.5 to 1.8 and thus my apps will not run at all on your installation of rbx or jruby. I have no idea why they ship with such old versions, but I've asked both the rbx and rvm guys.

@michaelklishin

It may surprise you but a lot of software out there still relies on 1.5 or even 1.3.7. As a benchmark: Heroku still uses 1.3.7. That's why. In any case, either try installing rubygems version you need in your before_script or use some other CI service. Supporting multiple versions of rubygems is non-trivial and no matter what version we choose, someone will be unhappy.

Given really low number of requests for this feature I conclude that what Rubies and RVM provide is a very sensible default and we are sticking to it.

@nicksieger

JRuby 1.6.5 will have RubyGems version 1.8.9.

@michaelklishin

One of the RVM team members says: «the rubygems is specific for each ruby and is NOT something that RVM arbitrarily imposes.»

@ddd

rubygems is specific for each ruby and is NOT something that RVM arbitrarily imposes.

we CAN update mri rubies to 1.8.10 but you would ahve to do a workaround such that you create 2 named-ruby installs and then use gem install ruby-update -v='x.x.x' within each one to the version needed, but you can not do that through rvm rubygems, nor can you swap back and forth between versions within a single ruby install.

@ddd
@ddd

However, forgive the harsh overtones there, Travis-CI. My apologies for allowing a troll to reduce me to responding in kind.

MY apologies to the project for that.

@svenfuchs
Owner

Let's all just try to be nice, people.

Travis-CI is about making things nicer, even though we might not always be able to support every usecase. Let's try to figure out if we can and otherwise explain things in a friendly way.

@rakaur a friendly tone is something you certainly can expect from us even if your own tone could have been friendlier, too :)

As @deryldoucette explained it seems that $ rvm rubygems can not be used to switch the rubygems version for rbx or jruby.

@rakaur

I deleted it right after I posted it for a reason: I regretted it. My general experience with the open source Ruby community has always been hostility. You could have realized I deleted it for a reason and not have responded thus proving my point.

I've been able to update RubyGems in before_script but now it seems jruby doesn't allow using gems with native extensions (at least on travis-ci.org) and so it was all for naught anyway.

And actually, rvm rubygems works fine with rbx, just not jruby.

@svenfuchs
Owner

I'm sorry to hear that this is your experience with the ruby community. My own experience is quite the opposite :)

I commented without reloading the page, so I didn't see you removed the comment. I'm sorry.

I believe native c extensions on jruby are a well known issue on travis-ci. I'm not quite sure what the current state is but I believe the jruby folks are working on it because this issue is not specific to travis-ci.

@michaelklishin can you give more information about this? and maybe how to work around it? can we have an faq answering this question? and maybe the rubygems question as well?

@rakaur

He quoted my email rather than my post, I'm pretty sure he knew it was deleted :)

I've been told you can set an environment variable to load jruby C extensions, but I can't find any info on it.

@svenfuchs
Owner

haha, no, i was not. but anyway ...

I think it's JRUBY_OPTS, but I'm not sure what you need to specify there exactly.

@ddd
@michaelklishin

C extensions are disabled on JRuby on travis-ci.org because

  1. They cause JVM crashes which is the single most common problem we hear about. JRuby core team members investigated it for a while and there is still no complete solution, only workarounds (that all boild down to not using C extensions).
  2. People should not be using C extensions on JRuby in production yet they often run CI with them, without even realizing that something like yajl-ruby has no Java implementation for JRuby or that sqlite3 gem has native part to it.

If someone really wants to load C extensions on JRuby (there are absolutely no reasons for doing that), she needs to override JRUBY_OPTS to not include -Dnative.enabled=false. Right now its value is

JRUBY_OPTS="--server -Dnative.enabled=false"

so, something like

env: JRUBY_OPTS='--server'

enables C extensions to be used again.

@rakaur
@svenfuchs
Owner

@rakaur would you be able to write up an faq question and answer about the painful things you've gone through here? (maybe except for the question if the ruby community is nice ... i still hope we can convince you we're the most lovable people on earth ;)

that would be incredibly cool, i'm absolutely sure there will be people running into the same things as you did today. our about page is here https://github.com/travis-ci/travis-ci.github.com feel free to submit a pull request. If that's too much work for you then any gist or email or even comment here would be super helpful, too!

thank you very much, sir!

@dbgrandi dbgrandi referenced this issue in CocoaPods/cocoapods-plugins
Merged

Issues/16 print out gem versions on a --verbose #28

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.