[Rubygems-developers] [ rubygems-Bugs-28155 ] source_index.rb uses 1.9.1 IO#read API under RUBY_VERSION 1.9.0; other 1.9.0 issues

noreply at rubyforge.org noreply at rubyforge.org
Sat Nov 13 08:52:23 EST 2010


Bugs item #28155, was opened at 2010-04-29 12:10
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28155&group_id=126

Category: other
Group: v1.3.x
Status: Open
>Resolution: Out of Date
Priority: 1
Submitted By: Randall Lucas (rlucas)
Assigned to: John Barnette (jbarnette)
Summary: source_index.rb uses 1.9.1 IO#read API under RUBY_VERSION 1.9.0; other 1.9.0 issues

Initial Comment:
Facially, this looks like an argument TypeError, and manifests thus:

/usr/local/lib/site_ruby/1.9/rubygems/source_index.rb:91:in `IO#read': can't convert Hash into Integer (TypeError)

In fact, it's a very similar issue to #28154.

source_index.rb at line 88 checks RUBY_VERSION < '1.9' before using the new :encoding => 'UTF-8' calling syntax for File.read (IO#read).

However, this change didn't make it into Ruby 1.9.0 (see below from core Changelog).

Again, the fix here is to check RUBY_VERSION < '1.9.1'

Similar errors may be lurking in config_file.rb, defaults.rb, vanidator.rb, and in the tests.


---
$ irb1.9
irb(main):001:0> File.open '/tmp/thing.txt' , :encoding => 'UTF-8'
TypeError: can't convert Hash into String
        from (irb):1:in `initialize'
        from (irb):1:in `Kernel#binding'

---
Fri Feb 15 16:22:49 2008  Yukihiro Matsumoto  <matz at ruby-lang.org>

    * io.c (open_key_args): allow specifying both :mode and :encoding.
---
$ ruby -v
ruby 1.9.0 (2006-06-08) [x86_64-linux]

$ gem ENV
RubyGems Environment:
  - RUBYGEMS VERSION: 1.3.6
  - RUBY VERSION: 1.9.0 (2006-06-08) [x86_64-linux]
  - INSTALLATION DIRECTORY: /usr/lib/ruby1.9/gems/1.9
  - RUBY EXECUTABLE: /usr/bin/ruby1.9
  - EXECUTABLE DIRECTORY: /usr/bin
  - RUBYGEMS PLATFORMS:
    - ruby
    - x86_64-linux
  - GEM PATHS:
     - /usr/lib/ruby1.9/gems/1.9
     - /home/rlucas/.gem/ruby/1.9
  - GEM CONFIGURATION:
     - :update_sources => true
     - :verbose => true
     - :benchmark => false
     - :backtrace => false
     - :bulk_threshold => 1000
  - REMOTE SOURCES:
     - http://rubygems.org/


----------------------------------------------------------------------

Comment By: John Barnette (jbarnette)
Date: 2010-11-13 05:35

Message:
I welcome a patch (preferably a pull request on GitHub) if this is still a concern. I'll close this ticket in a week or two if I don't see any activity.

----------------------------------------------------------------------

Comment By: Jason Frey (fryguy)
Date: 2010-06-23 13:40

Message:
I agree with Rob Anderson's disagreement.

I am using RubyGems 1.3.7 with both Ruby 1.8.6 and Ruby 1.8.7.  My project has REXML::Encoding loaded, so defined? Encoding passes when it shouldn't, and blows up with the can't convert Hash into Integer error.

I've changed source_index.rb:88 (similar to OP) to 
  spec_code = if RUBY_VERSION > '1.9.0' && defined? Encoding 
in order to get past the problem.

The mechanism of using defined? Encoding is insufficient if all that is needed is to determine the version of Ruby.  RUBY_VERSION feels like the more appropriate approach.

----------------------------------------------------------------------

Comment By: Randall Lucas (rlucas)
Date: 2010-05-25 22:13

Message:
I was using 1.9.0 because it was, and is, the Ruby 1.9 that
ships with Debian stable (both oldstable 4.x and current
stable 5.x).

It is bad to rely upon users not to use 1.9.0, because at
least one major *NIX distro includes it, and it is not
immediately apparent to the casual user/developer that 1.9.0
is special and untouchable.

That Rubygems should work on 1.8.X and 1.9.Y | Y >= 1
violates the principle of least surprise.  Whether or not
1.9.0 is intended for production is not the issue.  If
Rubygems is going to do version and/or symbol presence
checking that is known to break for this special case of
1.9.0, then it should do just one more version check and die
on invocation with 1.9.0, with a helpful message.

Seriously, for both this ticket and #28154, let's just
please stipulate that the API-change-induced version checks
should correspond to the actual versions in which the API
change is present.  The whole "> 1.9" vs. "> 1.9.0" shortcut
is bit-wise and byte-foolish.

----------------------------------------------------------------------

Comment By: Eric Hodel (drbrain)
Date: 2010-05-25 15:06

Message:
Why are you using 1.9.0?  AFAIK it was never intended for production use.

----------------------------------------------------------------------

Comment By: Rob Anderson (rabbashanks)
Date: 2010-05-24 04:30

Message:
I disagree that testing for the "Encoding" class name symbol is the better approach.  On my system (stats below), Encoding is defined by REXML as REXML::Encoding - so defined? Encoding returns true, despite my ruby version being 1.8.6

I have implemented the explicit check on RUBY_VERSION in my local copy of rubygems, but I would think this should be the way it is done for everyone.

ruby -v
ruby 1.8.6 (2007-09-24 patchlevel 111) [i686-darwin10.0.0]

gem ENV
RubyGems Environment:
  - RUBYGEMS VERSION: 1.3.7
  - RUBY VERSION: 1.8.6 (2007-09-24 patchlevel 111) [i686-darwin10.0.0]
  - INSTALLATION DIRECTORY: /usr/local/lib/ruby/gems/1.8
  - RUBY EXECUTABLE: /usr/local/bin/ruby
  - EXECUTABLE DIRECTORY: /usr/local/bin
  - RUBYGEMS PLATFORMS:
    - ruby
    - x86-darwin-10
  - GEM PATHS:
     - /usr/local/lib/ruby/gems/1.8
     - /Users/robanderson/.gem/ruby/1.8
  - GEM CONFIGURATION:
     - :update_sources => true
     - :verbose => true
     - :benchmark => false
     - :backtrace => false
     - :bulk_threshold => 1000
  - REMOTE SOURCES:
     - http://rubygems.org/


----------------------------------------------------------------------

Comment By: Randall Lucas (rlucas)
Date: 2010-05-01 10:48

Message:
This appears to have been fixed in trunk.  Current code
takes the better approach of testing for the "Encoding"
class name symbol, and specifying encoding if it exists (as
it does in 1.9.1 and above).

Lurking cousin errors to this, with the version check
assumption of consistent behavior for >= 1.9 (when in fact,
1.9.0 and 1.9.1 have pretty major API diffs), may linger here:

rubygems/commands/install_command.rb:112:    ENV.delete
'GEM_PATH' if options[:install_dir].nil? and RUBY_VERSION >
'1.9'

rubygems/config_file.rb:54:      if RUBY_VERSION > '1.9' then

rubygems/validator.rb:168:  if RUBY_VERSION < '1.9' then

rubygems/validator.rb:215:    if RUBY_VERSION < '1.9' then

rubygems.rb:500:    unless RUBY_VERSION > '1.9' then

rubygems.rb:1135:require 'rubygems/custom_require' if
gem_disabled or RUBY_VERSION < '1.9'


----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28155&group_id=126


More information about the Rubygems-developers mailing list