Help matching the right gems for MRI 1.8.7, 1.9.3, Rubinius and JRuby (rbx-require-relative)
Hi -
I have a gem, rbx-require-relative, that is
slightly different for MRI 1.8.7, MRI 1.9.2, MRI 1.9.3, Rubinius,
and JRuby. For version 0.0.7 I have:
0.0.7 February 26, 2012 universal-ruby-1.9.3
0.0.7 February 26, 2012 universal-rubinius-1.2
0.0.7 February 26, 2012 universal-ruby-1.8.7
If I have this right, in the above "universal" is the OS, "ruby" or "rubinius" the platform, and the version is listed last.
What I have noticed is that the wrong version is getting pulled down.
For example, I set ruby 1.9.3 in rvm:
$ rvm list
rvm rubies
jruby-1.5.6 [ i386 ]
rbx-2.0.0pre [ i686 ]
rbx-head [ i686 ]
rubinius-head [ i686 ]
ruby-1.8.7-p352 [ i686 ]
ruby-1.9.2-head-nframe [ i686 ]
ruby-1.9.2-p0 [ i686 ]
=> ruby-1.9.3-p125 [ i686 ]
# Default ruby not set. Try 'rvm alias create default <ruby>'.
# => - current
# =* - current && default
# * - default
When I run a gem search:
$ gem search -r rbx-require-relative
*** REMOTE GEMS ***
rbx-require-relative (0.0.7 universal-rubinius-1.2 universal-ruby-1.8.7 universal-ruby-1.9.3, 0.0.6 universal-jruby-1.2 universal-ruby-1.9.2, 0.0.5)
I am guessing that we stop at 0.0.5 because that is the matching gem. Right? If that is the case universal-ruby-1.9.3 is skipped over.
Or at any rate this is consistent with what I see:
$ gem install --remote --verbose rbx-require-relative
GET http://rubygems.org/latest_specs.4.8.gz
302 Found
GET http://production.s3.rubygems.org/latest_specs.4.8.gz
304 Not Modified
Installing gem rbx-require-relative-0.0.5
ERROR: Error installing rbx-require-relative:
rbx-require-relative requires Ruby version ~> 1.8.7.
$ gem --version
1.8.15
P.S. I was not sure if this should go as a Question or a Problem, but since many folks have been complaining about it a bit, I arbitrarily placed it as a Problem)
Comments are currently closed for this discussion. You can start a new one.
Support Staff 2 Posted by Eric Hodel on 27 Feb, 2012 06:38 PM
The platforms you are using are incorrect.
For a platform, the first value is the CPU type such as "universal" for multi-platform (such as a x86/x86_64 fat library) or "x86" for 32-bit Intel CPU
The second value is the OS type. For gems that do contain uncompiled C extensions this should be "ruby". A platform of "ruby" does not contain a CPU or version.
The third value is the OS version.
This is documented at
gem help platformTo see what platforms your ruby implementation supports, you can
gem env platform. Rubinius has a special platform of#{cpu}-rubinius-#{version}for a rubinius-specific version of a gem, or one with a rubinius-specific C extension.The best practice is to only use platforms for C extensions. If you are building against multiple ruby C API versions, include them all in the gem and require the correct built extension with a RUBY_VERSION check.
If you have a pure-ruby gem that has implementation-specific code, the best practice is to separate implementation-specific code into separate files and use a RUBY_ENGINE check to require the right file.
3 Posted by rockyb on 28 Feb, 2012 04:58 AM
Thanks for the information!
With this a new gem is out there which should resolve the previous woes, but I'm unable to yank all those versions that have erroneous platform names.
For example:
I am pretty sure I was able to do things like this yesterday.
I had wanted to a gem dependency based on the Ruby version, but given I've up on that. Also it strikes me as nicer to do the filtering on Ruby version number before download rather than during install or run-time, but this is another nicety I'll have to leave.
Again thanks for the help, and I am sorry for all the trouble this has caused.
Nick Quaranto closed this discussion on 04 Aug, 2012 06:07 PM.