Bugs item #28155, was opened at 2010-04-29 19: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: Closed
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 <m...@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: James Tucker (raggi)
Date: 2010-11-13 17:41
Message:
Not sure we want to support 1.9.0, besides, upgrades don't work right without
rebuilding ruby due to the core integration, so we should just wontfix.
Closing, reopen if any of the committers disagree.
----------------------------------------------------------------------
Comment By: John Barnette (jbarnette)
Date: 2010-11-13 13: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 20: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-26 05: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 22: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 11: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 17: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
_______________________________________________
Rubygems-developers mailing list
http://rubyforge.org/projects/rubygems
Rubygems-developers@rubyforge.org
http://rubyforge.org/mailman/listinfo/rubygems-developers
