From noreply at rubyforge.org Sat May 1 01:04:48 2010 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 1 May 2010 01:04:48 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-28154 ] Gem.binary_mode version test for Ruby 1.9 sets invalid rb:ascii-8bit mode Message-ID: <20100501050448.EF810185831F@rubyforge.org> Bugs item #28154, was opened at 2010-04-29 11:35 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28154&group_id=126 Category: other Group: v1.3.x Status: Open Resolution: None Priority: 3 Submitted By: Randall Lucas (rlucas) Assigned to: Nobody (None) Summary: Gem.binary_mode version test for Ruby 1.9 sets invalid rb:ascii-8bit mode Initial Comment: In rubygems.rb, line 344, self.binary_mode makes a check for RUBY_VERSION and sets @binary_mode accordingly. However, it assumes wrongly that the mode "rb:ascii-8bit" is available for all RUBY_VERSION > '1.9'. In fact, that mode does NOT work in Ruby 1.9.0, and was added in 1.9.1. (See support below from Ruby core SVN.) This manifests as a cryptic error: ERROR: While executing gem ... (ArgumentError) illegal access mode rb:ascii-8bit (full debugging error output below). Suggested fix: alter self.binary_mode to check for RUBY_VERSION > '1.9.0' thus: binary_mode ||= RUBY_VERSION > '1.9.0' ? 'rb:ascii-8bit' : 'rb' --- Support from Ruby core SVN for the mode name-change that breaks between 1.9.0 and 1.9.1: >From http://svn.ruby-lang.org/cgi-bin/viewvc.cgi/tags/v1_9_0_5/enc/ascii.c?view=log Revision 13670 - (view) (download) (annotate) - [select for diffs] Modified Wed Oct 10 06:50:33 2007 UTC (2 years, 6 months ago) by akr Original Path: trunk/ascii.c File length: 2408 byte(s) Diff to previous 12376 (colored) * encoding.c (rb_enc_init): don't alias iso-8859-1 to ascii. * ascii.c (OnigEncodingASCII): change the name US-ASCII to ASCII-8BIT. --- version info: $ uname -a Linux arrakis 2.6.18-6-amd64 #1 SMP Sat Feb 20 23:34:55 UTC 2010 x86_64 GNU/Linux $ ruby -v ruby 1.9.0 (2006-06-08) [x86_64-linux] $ sudo gem --debug install rake Exception `NameError' at /usr/local/lib/site_ruby/1.9/rubygems/command_manager.rb:163 - uninitialized constant Gem::Commands::InstallCommand Exception `Gem::LoadError' at /usr/local/lib/site_ruby/1.9/rubygems.rb:778 - Could not find RubyGem test-unit (>= 0) Exception `Gem::LoadError' at /usr/local/lib/site_ruby/1.9/rubygems.rb:778 - Could not find RubyGem sources (> 0.0.1) Exception `ArgumentError' at /usr/local/lib/site_ruby/1.9/rubygems/format.rb:50 - illegal access mode rb:ascii-8bit ERROR: While executing gem ... (ArgumentError) illegal access mode rb:ascii-8bit /usr/local/lib/site_ruby/1.9/rubygems/format.rb:50:in `initialize' /usr/local/lib/site_ruby/1.9/rubygems/format.rb:50:in `Gem::Format#from_file_by_path' /usr/local/lib/site_ruby/1.9/rubygems/installer.rb:118:in `initialize' /usr/local/lib/site_ruby/1.9/rubygems/dependency_installer.rb:257:in `Gem::DependencyInstaller#install' /usr/local/lib/site_ruby/1.9/rubygems/dependency_installer.rb:240:in `Gem::DependencyInstaller#install' /usr/local/lib/site_ruby/1.9/rubygems/commands/install_command.rb:119:in `execute' /usr/local/lib/site_ruby/1.9/rubygems/commands/install_command.rb:116:in `execute' /usr/local/lib/site_ruby/1.9/rubygems/command.rb:258:in `Gem::Command#invoke' /usr/local/lib/site_ruby/1.9/rubygems/command_manager.rb:134:in `process_args' /usr/local/lib/site_ruby/1.9/rubygems/command_manager.rb:104:in `Gem::CommandManager#run' /usr/local/lib/site_ruby/1.9/rubygems/gem_runner.rb:58:in `Gem::GemRunner#run' /usr/bin/gem:21 $ 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: Eric Hodel (drbrain) Date: 2010-04-30 22:04 Message: As far as I know 1.9.0 was never supposed to be a stable release used in production. There are no 1.9.0 releases in ftp.ruby-lang.org/pub/ruby and no patchlevels were released for it in /pub/ruby/1.9.0 (only snapshots). Is there some reason you can't use 1.9.1? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28154&group_id=126 From drbrain at segment7.net Sat May 1 01:07:55 2010 From: drbrain at segment7.net (Eric Hodel) Date: Fri, 30 Apr 2010 22:07:55 -0700 Subject: [Rubygems-developers] 1.3.7 ok to release? Message-ID: Other than the gem server fix are there any show-stoppers for RubyGems 1.3.7? I'm merging the one fix to ruby trunk so ruby 1.9.2 will ship with code identical to 1.3.7. From nick at quaran.to Sat May 1 09:41:18 2010 From: nick at quaran.to (Nick Quaranto) Date: Sat, 1 May 2010 09:41:18 -0400 Subject: [Rubygems-developers] 1.3.7 ok to release? In-Reply-To: References: Message-ID: I saw this: http://twitter.com/atmos/status/13173480639 I'm going to check in with both about it...if you can hold off until I can verify it I would appreciate it. On Sat, May 1, 2010 at 1:07 AM, Eric Hodel wrote: > Other than the gem server fix are there any show-stoppers for RubyGems > 1.3.7? > > I'm merging the one fix to ruby trunk so ruby 1.9.2 will ship with code > identical to 1.3.7. > _______________________________________________ > Rubygems-developers mailing list > http://rubyforge.org/projects/rubygems > Rubygems-developers at rubyforge.org > http://rubyforge.org/mailman/listinfo/rubygems-developers > From djberg96 at gmail.com Sat May 1 10:22:00 2010 From: djberg96 at gmail.com (Daniel Berger) Date: Sat, 1 May 2010 08:22:00 -0600 Subject: [Rubygems-developers] 1.3.7 ok to release? In-Reply-To: References: Message-ID: I tried to run the test suite on Windows 7 but ran into this: c:\Repositories\rubygems>rake test (in c:/Repositories/rubygems) rake aborted! no such file to load -- hoe C:/Ruby/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:2383:in `raw_load_rakefile' (See full trace by running task with --trace) c:\Repositories\rubygems>gem install hoe Successfully installed rubyforge-2.0.4 Successfully installed hoe-2.6.0 2 gems installed Installing ri documentation for rubyforge-2.0.4... Installing ri documentation for hoe-2.6.0... Installing RDoc documentation for rubyforge-2.0.4... Installing RDoc documentation for hoe-2.6.0... c:\Repositories\rubygems>rake test (in c:/Repositories/rubygems) rake aborted! No such file or directory - C:/Users/Daniel Berger/.rubyforge/user-config.yml C:/Ruby/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:2383:in `raw_load_rakefile' (See full trace by running task with --trace) Suggestions? Dan On Fri, Apr 30, 2010 at 11:07 PM, Eric Hodel wrote: > Other than the gem server fix are there any show-stoppers for RubyGems 1.3.7? > > I'm merging the one fix to ruby trunk so ruby 1.9.2 will ship with code identical to 1.3.7. > _______________________________________________ > Rubygems-developers mailing list > http://rubyforge.org/projects/rubygems > Rubygems-developers at rubyforge.org > http://rubyforge.org/mailman/listinfo/rubygems-developers > From luislavena at gmail.com Sat May 1 11:52:01 2010 From: luislavena at gmail.com (Luis Lavena) Date: Sat, 1 May 2010 12:52:01 -0300 Subject: [Rubygems-developers] 1.3.7 ok to release? In-Reply-To: References: Message-ID: On Sat, May 1, 2010 at 11:22 AM, Daniel Berger wrote: > I tried to run the test suite on Windows 7 but ran into this: > > c:\Repositories\rubygems>rake test > (in c:/Repositories/rubygems) > rake aborted! > no such file to load -- hoe > C:/Ruby/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:2383:in > `raw_load_rakefile' > (See full trace by running task with --trace) > > c:\Repositories\rubygems>gem install hoe > Successfully installed rubyforge-2.0.4 > Successfully installed hoe-2.6.0 > 2 gems installed > Installing ri documentation for rubyforge-2.0.4... > Installing ri documentation for hoe-2.6.0... > Installing RDoc documentation for rubyforge-2.0.4... > Installing RDoc documentation for hoe-2.6.0... > > c:\Repositories\rubygems>rake test > (in c:/Repositories/rubygems) > rake aborted! > No such file or directory - C:/Users/Daniel Berger/.rubyforge/user-config.yml > C:/Ruby/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:2383:in > `raw_load_rakefile' > (See full trace by running task with --trace) > > Suggestions? > "rubyforge setup" The problem is that Hoe is expecting rubyforge has been properly configured for you. Testing right now 1.8.6, 1.8.7, 1.9.1 and 1.9.2, be right back. -- Luis Lavena AREA 17 - Perfection in design is achieved not when there is nothing more to add, but rather when there is nothing more to take away. Antoine de Saint-Exup?ry From djberg96 at gmail.com Sat May 1 12:50:45 2010 From: djberg96 at gmail.com (Daniel Berger) Date: Sat, 1 May 2010 10:50:45 -0600 Subject: [Rubygems-developers] 1.3.7 ok to release? In-Reply-To: References: Message-ID: >> Suggestions? >> > > "rubyforge setup" > > The problem is that Hoe is expecting rubyforge has been properly > configured for you. I've never had to do anything manually before. What changed? Dan From luislavena at gmail.com Sat May 1 12:55:10 2010 From: luislavena at gmail.com (Luis Lavena) Date: Sat, 1 May 2010 13:55:10 -0300 Subject: [Rubygems-developers] 1.3.7 ok to release? In-Reply-To: References: Message-ID: On Sat, May 1, 2010 at 12:52 PM, Luis Lavena wrote: > [...] > > Testing right now 1.8.6, 1.8.7, 1.9.1 and 1.9.2, be right back. > http://pastie.org/941628 Things with 1.9.2 doesn't work now that "." is no longer in $LOAD_PATH -- Luis Lavena AREA 17 - Perfection in design is achieved not when there is nothing more to add, but rather when there is nothing more to take away. Antoine de Saint-Exup?ry From noreply at rubyforge.org Sat May 1 13:37:35 2010 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 1 May 2010 13:37:35 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-28154 ] Gem.binary_mode version test for Ruby 1.9 sets invalid rb:ascii-8bit mode Message-ID: <20100501173735.727511678312@rubyforge.org> Bugs item #28154, was opened at 2010-04-29 11:35 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28154&group_id=126 Category: other Group: v1.3.x Status: Open Resolution: None Priority: 3 Submitted By: Randall Lucas (rlucas) Assigned to: Nobody (None) Summary: Gem.binary_mode version test for Ruby 1.9 sets invalid rb:ascii-8bit mode Initial Comment: In rubygems.rb, line 344, self.binary_mode makes a check for RUBY_VERSION and sets @binary_mode accordingly. However, it assumes wrongly that the mode "rb:ascii-8bit" is available for all RUBY_VERSION > '1.9'. In fact, that mode does NOT work in Ruby 1.9.0, and was added in 1.9.1. (See support below from Ruby core SVN.) This manifests as a cryptic error: ERROR: While executing gem ... (ArgumentError) illegal access mode rb:ascii-8bit (full debugging error output below). Suggested fix: alter self.binary_mode to check for RUBY_VERSION > '1.9.0' thus: binary_mode ||= RUBY_VERSION > '1.9.0' ? 'rb:ascii-8bit' : 'rb' --- Support from Ruby core SVN for the mode name-change that breaks between 1.9.0 and 1.9.1: >From http://svn.ruby-lang.org/cgi-bin/viewvc.cgi/tags/v1_9_0_5/enc/ascii.c?view=log Revision 13670 - (view) (download) (annotate) - [select for diffs] Modified Wed Oct 10 06:50:33 2007 UTC (2 years, 6 months ago) by akr Original Path: trunk/ascii.c File length: 2408 byte(s) Diff to previous 12376 (colored) * encoding.c (rb_enc_init): don't alias iso-8859-1 to ascii. * ascii.c (OnigEncodingASCII): change the name US-ASCII to ASCII-8BIT. --- version info: $ uname -a Linux arrakis 2.6.18-6-amd64 #1 SMP Sat Feb 20 23:34:55 UTC 2010 x86_64 GNU/Linux $ ruby -v ruby 1.9.0 (2006-06-08) [x86_64-linux] $ sudo gem --debug install rake Exception `NameError' at /usr/local/lib/site_ruby/1.9/rubygems/command_manager.rb:163 - uninitialized constant Gem::Commands::InstallCommand Exception `Gem::LoadError' at /usr/local/lib/site_ruby/1.9/rubygems.rb:778 - Could not find RubyGem test-unit (>= 0) Exception `Gem::LoadError' at /usr/local/lib/site_ruby/1.9/rubygems.rb:778 - Could not find RubyGem sources (> 0.0.1) Exception `ArgumentError' at /usr/local/lib/site_ruby/1.9/rubygems/format.rb:50 - illegal access mode rb:ascii-8bit ERROR: While executing gem ... (ArgumentError) illegal access mode rb:ascii-8bit /usr/local/lib/site_ruby/1.9/rubygems/format.rb:50:in `initialize' /usr/local/lib/site_ruby/1.9/rubygems/format.rb:50:in `Gem::Format#from_file_by_path' /usr/local/lib/site_ruby/1.9/rubygems/installer.rb:118:in `initialize' /usr/local/lib/site_ruby/1.9/rubygems/dependency_installer.rb:257:in `Gem::DependencyInstaller#install' /usr/local/lib/site_ruby/1.9/rubygems/dependency_installer.rb:240:in `Gem::DependencyInstaller#install' /usr/local/lib/site_ruby/1.9/rubygems/commands/install_command.rb:119:in `execute' /usr/local/lib/site_ruby/1.9/rubygems/commands/install_command.rb:116:in `execute' /usr/local/lib/site_ruby/1.9/rubygems/command.rb:258:in `Gem::Command#invoke' /usr/local/lib/site_ruby/1.9/rubygems/command_manager.rb:134:in `process_args' /usr/local/lib/site_ruby/1.9/rubygems/command_manager.rb:104:in `Gem::CommandManager#run' /usr/local/lib/site_ruby/1.9/rubygems/gem_runner.rb:58:in `Gem::GemRunner#run' /usr/bin/gem:21 $ 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: Randall Lucas (rlucas) Date: 2010-05-01 10:37 Message: Well, the unsuitability of 1.9.0 is certainly crystal-clear to me *now.* But it *does* exist out there in the wild. Debian 4.0 and 5.0 (both the oldstable and stable) provide 1.9.0 as their Ruby 1.9 packages: http://packages.debian.org/lenny/interpreters/ruby1.9 http://packages.debian.org/etch/interpreters/ruby1.9 But the real issue here is the correctness of the version checks. I'm not so much suggesting that Rubygems be changed so as to accommodate 1.9.0, but rather asking that it not falsely give 1.9.0 credit for being a fully self-actualized and production-ready 1.9.1 version ;) ---------------------------------------------------------------------- Comment By: Eric Hodel (drbrain) Date: 2010-04-30 22:04 Message: As far as I know 1.9.0 was never supposed to be a stable release used in production. There are no 1.9.0 releases in ftp.ruby-lang.org/pub/ruby and no patchlevels were released for it in /pub/ruby/1.9.0 (only snapshots). Is there some reason you can't use 1.9.1? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28154&group_id=126 From noreply at rubyforge.org Sat May 1 13:43:22 2010 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 1 May 2010 13:43:22 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-28154 ] Gem.binary_mode version test for Ruby 1.9 sets invalid rb:ascii-8bit mode Message-ID: <20100501174322.1A66F1678312@rubyforge.org> Bugs item #28154, was opened at 2010-04-29 11:35 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28154&group_id=126 Category: other Group: v1.3.x Status: Open Resolution: None Priority: 3 Submitted By: Randall Lucas (rlucas) Assigned to: Nobody (None) Summary: Gem.binary_mode version test for Ruby 1.9 sets invalid rb:ascii-8bit mode Initial Comment: In rubygems.rb, line 344, self.binary_mode makes a check for RUBY_VERSION and sets @binary_mode accordingly. However, it assumes wrongly that the mode "rb:ascii-8bit" is available for all RUBY_VERSION > '1.9'. In fact, that mode does NOT work in Ruby 1.9.0, and was added in 1.9.1. (See support below from Ruby core SVN.) This manifests as a cryptic error: ERROR: While executing gem ... (ArgumentError) illegal access mode rb:ascii-8bit (full debugging error output below). Suggested fix: alter self.binary_mode to check for RUBY_VERSION > '1.9.0' thus: binary_mode ||= RUBY_VERSION > '1.9.0' ? 'rb:ascii-8bit' : 'rb' --- Support from Ruby core SVN for the mode name-change that breaks between 1.9.0 and 1.9.1: >From http://svn.ruby-lang.org/cgi-bin/viewvc.cgi/tags/v1_9_0_5/enc/ascii.c?view=log Revision 13670 - (view) (download) (annotate) - [select for diffs] Modified Wed Oct 10 06:50:33 2007 UTC (2 years, 6 months ago) by akr Original Path: trunk/ascii.c File length: 2408 byte(s) Diff to previous 12376 (colored) * encoding.c (rb_enc_init): don't alias iso-8859-1 to ascii. * ascii.c (OnigEncodingASCII): change the name US-ASCII to ASCII-8BIT. --- version info: $ uname -a Linux arrakis 2.6.18-6-amd64 #1 SMP Sat Feb 20 23:34:55 UTC 2010 x86_64 GNU/Linux $ ruby -v ruby 1.9.0 (2006-06-08) [x86_64-linux] $ sudo gem --debug install rake Exception `NameError' at /usr/local/lib/site_ruby/1.9/rubygems/command_manager.rb:163 - uninitialized constant Gem::Commands::InstallCommand Exception `Gem::LoadError' at /usr/local/lib/site_ruby/1.9/rubygems.rb:778 - Could not find RubyGem test-unit (>= 0) Exception `Gem::LoadError' at /usr/local/lib/site_ruby/1.9/rubygems.rb:778 - Could not find RubyGem sources (> 0.0.1) Exception `ArgumentError' at /usr/local/lib/site_ruby/1.9/rubygems/format.rb:50 - illegal access mode rb:ascii-8bit ERROR: While executing gem ... (ArgumentError) illegal access mode rb:ascii-8bit /usr/local/lib/site_ruby/1.9/rubygems/format.rb:50:in `initialize' /usr/local/lib/site_ruby/1.9/rubygems/format.rb:50:in `Gem::Format#from_file_by_path' /usr/local/lib/site_ruby/1.9/rubygems/installer.rb:118:in `initialize' /usr/local/lib/site_ruby/1.9/rubygems/dependency_installer.rb:257:in `Gem::DependencyInstaller#install' /usr/local/lib/site_ruby/1.9/rubygems/dependency_installer.rb:240:in `Gem::DependencyInstaller#install' /usr/local/lib/site_ruby/1.9/rubygems/commands/install_command.rb:119:in `execute' /usr/local/lib/site_ruby/1.9/rubygems/commands/install_command.rb:116:in `execute' /usr/local/lib/site_ruby/1.9/rubygems/command.rb:258:in `Gem::Command#invoke' /usr/local/lib/site_ruby/1.9/rubygems/command_manager.rb:134:in `process_args' /usr/local/lib/site_ruby/1.9/rubygems/command_manager.rb:104:in `Gem::CommandManager#run' /usr/local/lib/site_ruby/1.9/rubygems/gem_runner.rb:58:in `Gem::GemRunner#run' /usr/bin/gem:21 $ 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: Randall Lucas (rlucas) Date: 2010-05-01 10:43 Message: Looks like it's fixed in trunk anyhow. FYI. ---------------------------------------------------------------------- Comment By: Randall Lucas (rlucas) Date: 2010-05-01 10:37 Message: Well, the unsuitability of 1.9.0 is certainly crystal-clear to me *now.* But it *does* exist out there in the wild. Debian 4.0 and 5.0 (both the oldstable and stable) provide 1.9.0 as their Ruby 1.9 packages: http://packages.debian.org/lenny/interpreters/ruby1.9 http://packages.debian.org/etch/interpreters/ruby1.9 But the real issue here is the correctness of the version checks. I'm not so much suggesting that Rubygems be changed so as to accommodate 1.9.0, but rather asking that it not falsely give 1.9.0 credit for being a fully self-actualized and production-ready 1.9.1 version ;) ---------------------------------------------------------------------- Comment By: Eric Hodel (drbrain) Date: 2010-04-30 22:04 Message: As far as I know 1.9.0 was never supposed to be a stable release used in production. There are no 1.9.0 releases in ftp.ruby-lang.org/pub/ruby and no patchlevels were released for it in /pub/ruby/1.9.0 (only snapshots). Is there some reason you can't use 1.9.1? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28154&group_id=126 From noreply at rubyforge.org Sat May 1 13:48:41 2010 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 1 May 2010 13:48:41 -0400 (EDT) Subject: [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 Message-ID: <20100501174841.8F819185833D@rubyforge.org> 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: None Priority: 3 Submitted By: Randall Lucas (rlucas) Assigned to: Nobody (None) 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 * 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: 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 From luislavena at gmail.com Sat May 1 14:07:38 2010 From: luislavena at gmail.com (Luis Lavena) Date: Sat, 1 May 2010 15:07:38 -0300 Subject: [Rubygems-developers] 1.3.7 ok to release? In-Reply-To: References: Message-ID: On Sat, May 1, 2010 at 1:50 PM, Daniel Berger wrote: > > I've never had to do anything manually before. What changed? > Did you had setup rubyforge in that computer? RubyGems switch to Hoe a while back, and with Hoe switch, rubyforge dependency came along. -- Luis Lavena AREA 17 - Perfection in design is achieved not when there is nothing more to add, but rather when there is nothing more to take away. Antoine de Saint-Exup?ry From ryand-ruby at zenspider.com Mon May 3 04:05:22 2010 From: ryand-ruby at zenspider.com (Ryan Davis) Date: Mon, 3 May 2010 01:05:22 -0700 Subject: [Rubygems-developers] 1.3.7 ok to release? In-Reply-To: References: Message-ID: <7618A6D4-E0EF-49FE-813E-4F17D0ABE314@zenspider.com> On May 1, 2010, at 09:55 , Luis Lavena wrote: > On Sat, May 1, 2010 at 12:52 PM, Luis Lavena wrote: >> [...] >> >> Testing right now 1.8.6, 1.8.7, 1.9.1 and 1.9.2, be right back. >> > > http://pastie.org/941628 > > Things with 1.9.2 doesn't work now that "." is no longer in $LOAD_PATH I've got a change to hoe that'll fix that. sorry. From luislavena at gmail.com Mon May 3 11:08:51 2010 From: luislavena at gmail.com (Luis Lavena) Date: Mon, 3 May 2010 12:08:51 -0300 Subject: [Rubygems-developers] 1.3.7 ok to release? In-Reply-To: <7618A6D4-E0EF-49FE-813E-4F17D0ABE314@zenspider.com> References: <7618A6D4-E0EF-49FE-813E-4F17D0ABE314@zenspider.com> Message-ID: On Mon, May 3, 2010 at 5:05 AM, Ryan Davis wrote: > > On May 1, 2010, at 09:55 , Luis Lavena wrote: > >> On Sat, May 1, 2010 at 12:52 PM, Luis Lavena wrote: >>> [...] >>> >>> Testing right now 1.8.6, 1.8.7, 1.9.1 and 1.9.2, be right back. >>> >> >> http://pastie.org/941628 >> >> Things with 1.9.2 doesn't work now that "." is no longer in $LOAD_PATH > > I've got a change to hoe that'll fix that. sorry. > No problem. Since 1.9.2 is deprecating YAML.quick_emit, I think 1.3.7 should go out with a fix for that in specification.rb Eric: what do you think? -- Luis Lavena AREA 17 - Perfection in design is achieved not when there is nothing more to add, but rather when there is nothing more to take away. Antoine de Saint-Exup?ry From noreply at rubyforge.org Mon May 3 12:34:49 2010 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 3 May 2010 12:34:49 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Feature Requests-28167 ] print backtraces from errors when $DEBUG env variable is set Message-ID: <20100503163449.EDFB618582EE@rubyforge.org> Feature Requests item #28167, was opened at 2010-05-03 10:34 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=578&aid=28167&group_id=126 Category: `gem` commands Group: v1.3.x Status: Open Resolution: None Priority: 3 Submitted By: Daniel DeLeo (danielsdeleo) Assigned to: Nobody (None) Summary: print backtraces from errors when $DEBUG env variable is set Initial Comment: When developing rubygems plugins, it would be helpful to see the backtraces from errors I cause. I imagine this would also be useful when reporting bugs. Rubygems should allow users to opt in to printing backtraces by setting a DEBUG environment variable. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=578&aid=28167&group_id=126 From drbrain at segment7.net Mon May 3 16:13:51 2010 From: drbrain at segment7.net (Eric Hodel) Date: Mon, 3 May 2010 13:13:51 -0700 Subject: [Rubygems-developers] 1.3.7 ok to release? In-Reply-To: References: <7618A6D4-E0EF-49FE-813E-4F17D0ABE314@zenspider.com> Message-ID: On May 3, 2010, at 08:08, Luis Lavena wrote: > Since 1.9.2 is deprecating YAML.quick_emit, I think 1.3.7 should go > out with a fix for that in specification.rb > > Eric: what do you think? Aaron (author of Psych) gave me a patch that handles this correctly for both Syck and Psych, so 1.3.7 is forward and backward compatible. From drbrain at segment7.net Mon May 3 16:34:31 2010 From: drbrain at segment7.net (Eric Hodel) Date: Mon, 3 May 2010 13:34:31 -0700 Subject: [Rubygems-developers] 1.3.7 ok to release? In-Reply-To: References: Message-ID: On May 1, 2010, at 09:55, Luis Lavena wrote: > On Sat, May 1, 2010 at 12:52 PM, Luis Lavena wrote: >> [...] >> >> Testing right now 1.8.6, 1.8.7, 1.9.1 and 1.9.2, be right back. >> > > http://pastie.org/941628 > > Things with 1.9.2 doesn't work now that "." is no longer in $LOAD_PATH Looks like your failures are all due to yard being installed. From noreply at rubyforge.org Tue May 4 00:39:09 2010 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 4 May 2010 00:39:09 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-27087 ] Rubygems 1.3.5 and Ruby 1.9 breaks hard after require 'rubygems/specification' Message-ID: <20100504043909.1A52D1858322@rubyforge.org> Bugs item #27087, was opened at 2009-09-10 20:34 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27087&group_id=126 Category: #gem and #require methods Group: None Status: Open Resolution: None Priority: 1 Submitted By: Rob Sanheim (rsanheim) Assigned to: Eric Hodel (drbrain) Summary: Rubygems 1.3.5 and Ruby 1.9 breaks hard after require 'rubygems/specification' Initial Comment: Please see the repo: http://github.com/rsanheim/ruby19_rubygems_bug/tree/master The build is here: http://runcoderun.com/rsanheim/ruby19_rubygems_bug The failing build on Ruby 1.9.1 p243: http://runcoderun.com/rsanheim/ruby19_rubygems_bug http://runcoderun.com/rsanheim/ruby19_rubygems_bug/builds/09a9f683fe7848980e10ac7bd2291040ec11ea17/1/ruby_191 Here is the simplest code to illustrate: require 'hoe' gem 'hoe' # these should work puts "about to break 'gem'" require 'rubygems/specification' gem 'hoe' # exception thrown here when it shouldn't be ---------------------------------------------------------------------- Comment By: Hedge Hog (hedgehog) Date: 2010-05-04 04:39 Message: Also affects: ruby 1.9.2dev (2009-07-18 trunk 24186) [x86_64-linux] ---------------------------------------------------------------------- Comment By: Eric Hodel (drbrain) Date: 2010-04-22 03:54 Message: I'm not entirely sure how this is breaking, but require 'rubygems' provides Gem::Specification, so you don't need to require it. The workaround is to not require 'rubygems/specification'. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2009-09-11 07:30 Message: We've already tracked down the problem. The workaround as described is to remove your manually installed rubygems from 1.9.x. ---------------------------------------------------------------------- Comment By: Adam Salter (aqsalter) Date: 2009-09-11 06:33 Message: Ryan: Sorry about that. I (too) am working on several projects, busy and wanted to throw in my helpful comments... I find problems can get fixed quicker if the devs know how many people are affected. I misunderstood your initial comment: '0 failures out of 4' sounds like no failures, which could certainly be assumed to be a good thing - except we are trying to track down a problem. +1 biting off a much ruder comment and looking to the future with hope and optimism. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2009-09-11 06:08 Message: Please don't +1. That shit is obnoxious. We don't need to test this against jeweler if we have a much cleaner smaller repro that is standalone. ---------------------------------------------------------------------- Comment By: Adam Salter (aqsalter) Date: 2009-09-11 01:47 Message: +1 please fix... Not exactly 'urgent' but annoying. I raised a bug on the 'jeweler' gem because of this: http://github.com/technicalpickles/jeweler/issues#issue/34 I'm sure that the code i provide there: Rakefile: require 'jeweler' rake -T will trigger issue. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2009-09-10 20:54 Message: Huh! % sudo gem uninstall rubygems-update % multiruby -rubygems -rrubygems/specification -e 'gem "hoe"' ... TOTAL RESULT = 0 failures out of 4 Passed: 1.9.1-p129, 1.8.7-p72, 1.8.7-p160, 1.8.6-p368 ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2009-09-10 20:53 Message: Easier repro of the warnings: multiruby -rubygems -rrubygems/specification -e 0 and: multiruby -rubygems -rrubygems/specification -e 'gem "hoe"' ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27087&group_id=126 From noreply at rubyforge.org Tue May 4 01:49:47 2010 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 4 May 2010 01:49:47 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-27087 ] Rubygems 1.3.5 and Ruby 1.9 breaks hard after require 'rubygems/specification' Message-ID: <20100504054947.0DBB21858320@rubyforge.org> Bugs item #27087, was opened at 2009-09-10 20:34 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27087&group_id=126 Category: #gem and #require methods Group: None Status: Open Resolution: None Priority: 1 Submitted By: Rob Sanheim (rsanheim) Assigned to: Eric Hodel (drbrain) Summary: Rubygems 1.3.5 and Ruby 1.9 breaks hard after require 'rubygems/specification' Initial Comment: Please see the repo: http://github.com/rsanheim/ruby19_rubygems_bug/tree/master The build is here: http://runcoderun.com/rsanheim/ruby19_rubygems_bug The failing build on Ruby 1.9.1 p243: http://runcoderun.com/rsanheim/ruby19_rubygems_bug http://runcoderun.com/rsanheim/ruby19_rubygems_bug/builds/09a9f683fe7848980e10ac7bd2291040ec11ea17/1/ruby_191 Here is the simplest code to illustrate: require 'hoe' gem 'hoe' # these should work puts "about to break 'gem'" require 'rubygems/specification' gem 'hoe' # exception thrown here when it shouldn't be ---------------------------------------------------------------------- Comment By: Hedge Hog (hedgehog) Date: 2010-05-04 05:49 Message: The following is a minimal rvm example, the `rake -T` command triggers the issue here too: bash < <( curl http://rvm.beginrescueend.com/releases/rvm-install-head ) cat >~/.bash_profile <&1|tee /tmp/rake-t-error.log popd popd The rake log is here: http://www.pastie.org/944745 HTH? gem list --local *** LOCAL GEMS *** rake (0.8.7) rdoc (2.5.8) ---------------------------------------------------------------------- Comment By: Hedge Hog (hedgehog) Date: 2010-05-04 04:39 Message: Also affects: ruby 1.9.2dev (2009-07-18 trunk 24186) [x86_64-linux] ---------------------------------------------------------------------- Comment By: Eric Hodel (drbrain) Date: 2010-04-22 03:54 Message: I'm not entirely sure how this is breaking, but require 'rubygems' provides Gem::Specification, so you don't need to require it. The workaround is to not require 'rubygems/specification'. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2009-09-11 07:30 Message: We've already tracked down the problem. The workaround as described is to remove your manually installed rubygems from 1.9.x. ---------------------------------------------------------------------- Comment By: Adam Salter (aqsalter) Date: 2009-09-11 06:33 Message: Ryan: Sorry about that. I (too) am working on several projects, busy and wanted to throw in my helpful comments... I find problems can get fixed quicker if the devs know how many people are affected. I misunderstood your initial comment: '0 failures out of 4' sounds like no failures, which could certainly be assumed to be a good thing - except we are trying to track down a problem. +1 biting off a much ruder comment and looking to the future with hope and optimism. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2009-09-11 06:08 Message: Please don't +1. That shit is obnoxious. We don't need to test this against jeweler if we have a much cleaner smaller repro that is standalone. ---------------------------------------------------------------------- Comment By: Adam Salter (aqsalter) Date: 2009-09-11 01:47 Message: +1 please fix... Not exactly 'urgent' but annoying. I raised a bug on the 'jeweler' gem because of this: http://github.com/technicalpickles/jeweler/issues#issue/34 I'm sure that the code i provide there: Rakefile: require 'jeweler' rake -T will trigger issue. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2009-09-10 20:54 Message: Huh! % sudo gem uninstall rubygems-update % multiruby -rubygems -rrubygems/specification -e 'gem "hoe"' ... TOTAL RESULT = 0 failures out of 4 Passed: 1.9.1-p129, 1.8.7-p72, 1.8.7-p160, 1.8.6-p368 ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2009-09-10 20:53 Message: Easier repro of the warnings: multiruby -rubygems -rrubygems/specification -e 0 and: multiruby -rubygems -rrubygems/specification -e 'gem "hoe"' ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27087&group_id=126 From luislavena at gmail.com Tue May 4 10:28:13 2010 From: luislavena at gmail.com (Luis Lavena) Date: Tue, 4 May 2010 11:28:13 -0300 Subject: [Rubygems-developers] 1.3.7 ok to release? In-Reply-To: References: Message-ID: On Mon, May 3, 2010 at 5:34 PM, Eric Hodel wrote: > > On May 1, 2010, at 09:55, Luis Lavena wrote: >> >> http://pastie.org/941628 >> > > Looks like your failures are all due to yard being installed. The weirdest part is that I uninstalled the yard gem. Will try again, maybe I should stop testing so late during the day. -- Luis Lavena AREA 17 - Perfection in design is achieved not when there is nothing more to add, but rather when there is nothing more to take away. Antoine de Saint-Exup?ry From noreply at rubyforge.org Tue May 4 16:26:18 2010 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 4 May 2010 16:26:18 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-27087 ] Rubygems 1.3.5 and Ruby 1.9 breaks hard after require 'rubygems/specification' Message-ID: <20100504202618.D24E2185833F@rubyforge.org> Bugs item #27087, was opened at 2009-09-10 13:34 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27087&group_id=126 Category: #gem and #require methods Group: None Status: Open Resolution: None Priority: 1 Submitted By: Rob Sanheim (rsanheim) Assigned to: Eric Hodel (drbrain) Summary: Rubygems 1.3.5 and Ruby 1.9 breaks hard after require 'rubygems/specification' Initial Comment: Please see the repo: http://github.com/rsanheim/ruby19_rubygems_bug/tree/master The build is here: http://runcoderun.com/rsanheim/ruby19_rubygems_bug The failing build on Ruby 1.9.1 p243: http://runcoderun.com/rsanheim/ruby19_rubygems_bug http://runcoderun.com/rsanheim/ruby19_rubygems_bug/builds/09a9f683fe7848980e10ac7bd2291040ec11ea17/1/ruby_191 Here is the simplest code to illustrate: require 'hoe' gem 'hoe' # these should work puts "about to break 'gem'" require 'rubygems/specification' gem 'hoe' # exception thrown here when it shouldn't be ---------------------------------------------------------------------- >Comment By: Eric Hodel (drbrain) Date: 2010-05-04 13:26 Message: Why are you requiring rubygems/specification? require 'rubygems' provides it for you. ---------------------------------------------------------------------- Comment By: Hedge Hog (hedgehog) Date: 2010-05-03 22:49 Message: The following is a minimal rvm example, the `rake -T` command triggers the issue here too: bash < <( curl http://rvm.beginrescueend.com/releases/rvm-install-head ) cat >~/.bash_profile <&1|tee /tmp/rake-t-error.log popd popd The rake log is here: http://www.pastie.org/944745 HTH? gem list --local *** LOCAL GEMS *** rake (0.8.7) rdoc (2.5.8) ---------------------------------------------------------------------- Comment By: Hedge Hog (hedgehog) Date: 2010-05-03 21:39 Message: Also affects: ruby 1.9.2dev (2009-07-18 trunk 24186) [x86_64-linux] ---------------------------------------------------------------------- Comment By: Eric Hodel (drbrain) Date: 2010-04-21 20:54 Message: I'm not entirely sure how this is breaking, but require 'rubygems' provides Gem::Specification, so you don't need to require it. The workaround is to not require 'rubygems/specification'. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2009-09-11 00:30 Message: We've already tracked down the problem. The workaround as described is to remove your manually installed rubygems from 1.9.x. ---------------------------------------------------------------------- Comment By: Adam Salter (aqsalter) Date: 2009-09-10 23:33 Message: Ryan: Sorry about that. I (too) am working on several projects, busy and wanted to throw in my helpful comments... I find problems can get fixed quicker if the devs know how many people are affected. I misunderstood your initial comment: '0 failures out of 4' sounds like no failures, which could certainly be assumed to be a good thing - except we are trying to track down a problem. +1 biting off a much ruder comment and looking to the future with hope and optimism. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2009-09-10 23:08 Message: Please don't +1. That shit is obnoxious. We don't need to test this against jeweler if we have a much cleaner smaller repro that is standalone. ---------------------------------------------------------------------- Comment By: Adam Salter (aqsalter) Date: 2009-09-10 18:47 Message: +1 please fix... Not exactly 'urgent' but annoying. I raised a bug on the 'jeweler' gem because of this: http://github.com/technicalpickles/jeweler/issues#issue/34 I'm sure that the code i provide there: Rakefile: require 'jeweler' rake -T will trigger issue. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2009-09-10 13:54 Message: Huh! % sudo gem uninstall rubygems-update % multiruby -rubygems -rrubygems/specification -e 'gem "hoe"' ... TOTAL RESULT = 0 failures out of 4 Passed: 1.9.1-p129, 1.8.7-p72, 1.8.7-p160, 1.8.6-p368 ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2009-09-10 13:53 Message: Easier repro of the warnings: multiruby -rubygems -rrubygems/specification -e 0 and: multiruby -rubygems -rrubygems/specification -e 'gem "hoe"' ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27087&group_id=126 From noreply at rubyforge.org Sun May 9 00:23:57 2010 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 9 May 2010 00:23:57 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-27087 ] Rubygems 1.3.5 and Ruby 1.9 breaks hard after require 'rubygems/specification' Message-ID: <20100509042357.C5EB7185831F@rubyforge.org> Bugs item #27087, was opened at 2009-09-10 20:34 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27087&group_id=126 Category: #gem and #require methods Group: None Status: Open Resolution: None Priority: 1 Submitted By: Rob Sanheim (rsanheim) Assigned to: Eric Hodel (drbrain) Summary: Rubygems 1.3.5 and Ruby 1.9 breaks hard after require 'rubygems/specification' Initial Comment: Please see the repo: http://github.com/rsanheim/ruby19_rubygems_bug/tree/master The build is here: http://runcoderun.com/rsanheim/ruby19_rubygems_bug The failing build on Ruby 1.9.1 p243: http://runcoderun.com/rsanheim/ruby19_rubygems_bug http://runcoderun.com/rsanheim/ruby19_rubygems_bug/builds/09a9f683fe7848980e10ac7bd2291040ec11ea17/1/ruby_191 Here is the simplest code to illustrate: require 'hoe' gem 'hoe' # these should work puts "about to break 'gem'" require 'rubygems/specification' gem 'hoe' # exception thrown here when it shouldn't be ---------------------------------------------------------------------- Comment By: Hedge Hog (hedgehog) Date: 2010-05-09 04:23 Message: Why I'm not yet sure but it is called after rake/gempackagetask. Specifically: require 'rubygems' require 'rake/gempackagetask' require 'rubygems/specification' If I comment out the require 'rubygems/specification' I still get a failure: http://www.pastie.org/952149 I'm yet to get my head around how/why Chef has to use this sequence.... they may not be alone. It is still a useful example of a reproducible case that is minimal: $ gem list --local *** LOCAL GEMS *** rake (0.8.7) rdoc (2.5.8) HTH? ---------------------------------------------------------------------- Comment By: Eric Hodel (drbrain) Date: 2010-05-04 20:26 Message: Why are you requiring rubygems/specification? require 'rubygems' provides it for you. ---------------------------------------------------------------------- Comment By: Hedge Hog (hedgehog) Date: 2010-05-04 05:49 Message: The following is a minimal rvm example, the `rake -T` command triggers the issue here too: bash < <( curl http://rvm.beginrescueend.com/releases/rvm-install-head ) cat >~/.bash_profile <&1|tee /tmp/rake-t-error.log popd popd The rake log is here: http://www.pastie.org/944745 HTH? gem list --local *** LOCAL GEMS *** rake (0.8.7) rdoc (2.5.8) ---------------------------------------------------------------------- Comment By: Hedge Hog (hedgehog) Date: 2010-05-04 04:39 Message: Also affects: ruby 1.9.2dev (2009-07-18 trunk 24186) [x86_64-linux] ---------------------------------------------------------------------- Comment By: Eric Hodel (drbrain) Date: 2010-04-22 03:54 Message: I'm not entirely sure how this is breaking, but require 'rubygems' provides Gem::Specification, so you don't need to require it. The workaround is to not require 'rubygems/specification'. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2009-09-11 07:30 Message: We've already tracked down the problem. The workaround as described is to remove your manually installed rubygems from 1.9.x. ---------------------------------------------------------------------- Comment By: Adam Salter (aqsalter) Date: 2009-09-11 06:33 Message: Ryan: Sorry about that. I (too) am working on several projects, busy and wanted to throw in my helpful comments... I find problems can get fixed quicker if the devs know how many people are affected. I misunderstood your initial comment: '0 failures out of 4' sounds like no failures, which could certainly be assumed to be a good thing - except we are trying to track down a problem. +1 biting off a much ruder comment and looking to the future with hope and optimism. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2009-09-11 06:08 Message: Please don't +1. That shit is obnoxious. We don't need to test this against jeweler if we have a much cleaner smaller repro that is standalone. ---------------------------------------------------------------------- Comment By: Adam Salter (aqsalter) Date: 2009-09-11 01:47 Message: +1 please fix... Not exactly 'urgent' but annoying. I raised a bug on the 'jeweler' gem because of this: http://github.com/technicalpickles/jeweler/issues#issue/34 I'm sure that the code i provide there: Rakefile: require 'jeweler' rake -T will trigger issue. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2009-09-10 20:54 Message: Huh! % sudo gem uninstall rubygems-update % multiruby -rubygems -rrubygems/specification -e 'gem "hoe"' ... TOTAL RESULT = 0 failures out of 4 Passed: 1.9.1-p129, 1.8.7-p72, 1.8.7-p160, 1.8.6-p368 ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2009-09-10 20:53 Message: Easier repro of the warnings: multiruby -rubygems -rrubygems/specification -e 0 and: multiruby -rubygems -rrubygems/specification -e 'gem "hoe"' ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27087&group_id=126 From noreply at rubyforge.org Sun May 9 04:14:46 2010 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 9 May 2010 04:14:46 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-22770 ] Gem::InstallError when running gem clean in osx 10.5.5 (v.1.3.1) Message-ID: <20100509081446.4FE8C1D799C5@rubyforge.org> Bugs item #22770, was opened at 2008-11-12 09:34 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=22770&group_id=126 Category: `gem` commands (other) Group: v1.3.x Status: Closed Resolution: Accepted Priority: 3 Submitted By: Andrew Reeve (dru) Assigned to: Daniel Berger (djberg96) Summary: Gem::InstallError when running gem clean in osx 10.5.5 (v.1.3.1) Initial Comment: Since updating to ruygems 1.3.1 (from 1.2) whenever I run sudo gem clean I get the following message for any gem version that comes bundled with leopard: Cleaning up installed gems... Attempting to uninstall ferret-0.11.4 ERROR: While executing gem ... (Gem::InstallError) Unknown gem ferret = 0.11.4 With rubygems 1.2 it used to just skip over the pre-installed gems when I tried to clean and then carried on cleaning up the other gems. Now, because of this error it stops straight away meaning I have to do all of my cleanup by hand a gem at a time. Initially I though my gems were broken, but if I drop back down to rubygems 1.2 everything works fine, and in the interests of being thorough this problem also persists after I do a clean install of the entire operating system. This is the output of "gem env" RubyGems Environment: - RUBYGEMS VERSION: 1.3.1 - RUBY VERSION: 1.8.6 (2008-03-03 patchlevel 114) [universal-darwin9.0] - INSTALLATION DIRECTORY: /Library/Ruby/Gems/1.8 - RUBY EXECUTABLE: /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/ruby - EXECUTABLE DIRECTORY: /usr/bin - RUBYGEMS PLATFORMS: - ruby - universal-darwin-9 - GEM PATHS: - /Library/Ruby/Gems/1.8 - /Users/Dru/.gem/ruby/1.8 - /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/gems/1.8 - GEM CONFIGURATION: - :update_sources => true - :verbose => true - :benchmark => false - :backtrace => false - :bulk_threshold => 1000 - :sources => ["http://gems.rubyforge.org", "http://gems.github.com"] - REMOTE SOURCES: - http://gems.rubyforge.org - http://gems.github.com and this is the debug information from when I run "sudo gem clean" [Dru ~] sudo gem --debug clean Password: Exception `NameError' at /Library/Ruby/Site/1.8/rubygems/command_manager.rb:134 - uninitialized constant Gem::Commands::CleanupCommand Cleaning up installed gems... Exception `NameError' at /Library/Ruby/Site/1.8/rubygems/command_manager.rb:134 - uninitialized constant Gem::Commands::UninstallCommand Attempting to uninstall ferret-0.11.4 Exception `Gem::InstallError' at /Library/Ruby/Site/1.8/rubygems/uninstaller.rb:61 - Unknown gem ferret = 0.11.4 ERROR: While executing gem ... (Gem::InstallError) Unknown gem ferret = 0.11.4 /Library/Ruby/Site/1.8/rubygems/uninstaller.rb:61:in `uninstall' /Library/Ruby/Site/1.8/rubygems/commands/cleanup_command.rb:78:in `execute' /Library/Ruby/Site/1.8/rubygems/commands/cleanup_command.rb:65:in `each' /Library/Ruby/Site/1.8/rubygems/commands/cleanup_command.rb:65:in `execute' /Library/Ruby/Site/1.8/rubygems/command.rb:136:in `invoke' /Library/Ruby/Site/1.8/rubygems/command_manager.rb:105:in `process_args' /Library/Ruby/Site/1.8/rubygems/command_manager.rb:75:in `run' /Library/Ruby/Site/1.8/rubygems/gem_runner.rb:39:in `run' /usr/bin/gem:24 It's almost like it isn't seeing the gem repository located in "/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/gems/1.8" I'll gladly submit any additional information you might need. ---------------------------------------------------------------------- Comment By: Hedge Hog (hedgehog) Date: 2010-05-09 08:14 Message: Also seeing this on ruby-1.9.1-p378, installed under rvm. $ gem cleanup --debug Exception `NameError' at /home/hedge/.rvm/rubies/ruby-1.9.1-p378/lib/ruby/site_ruby/1.9.1/rubygems/command_manager.rb:163 - uninitialized constant Gem::Commands::CleanupCommand Cleaning up installed gems... Clean Up Complete $ gem env RubyGems Environment: - RUBYGEMS VERSION: 1.3.6 - RUBY VERSION: 1.9.1 (2010-01-10 patchlevel 378) [x86_64-linux] - INSTALLATION DIRECTORY: /home/hedge/.rvm/gems/ruby-1.9.1-p378 - RUBY EXECUTABLE: /home/hedge/.rvm/rubies/ruby-1.9.1-p378/bin/ruby - EXECUTABLE DIRECTORY: /home/hedge/.rvm/gems/ruby-1.9.1-p378/bin - RUBYGEMS PLATFORMS: - ruby - x86_64-linux - GEM PATHS: - /home/hedge/.rvm/gems/ruby-1.9.1-p378 - /home/hedge/.rvm/gems/ruby-1.9.1-p378 at global - GEM CONFIGURATION: - :update_sources => true - :verbose => true - :benchmark => false - :backtrace => false - :bulk_threshold => 1000 - :gem => "--no-rdoc --no-ri" - REMOTE SOURCES: - http://rubygems.org/ ---------------------------------------------------------------------- Comment By: John Stehle (jstehle) Date: 2009-03-10 18:44 Message: What was the fix. Is there a patch available? or should I do a gem update --system? Thanks ---------------------------------------------------------------------- Comment By: Eric Hodel (drbrain) Date: 2009-03-08 21:04 Message: Fixed by Ryan Davis. ---------------------------------------------------------------------- Comment By: Daniel Berger (djberg96) Date: 2009-02-11 06:09 Message: Not much to report at the moment. This is going to be a tough one to solve I'm sorry to say. Much tougher than it ought to be. Dan ---------------------------------------------------------------------- Comment By: John Stehle (jstehle) Date: 2009-02-10 18:13 Message: Any update on this? Thanks ---------------------------------------------------------------------- Comment By: John Stehle (jstehle) Date: 2009-01-28 20:50 Message: I am on a MacBook OS X 10.5.6 and I am having the same issues with clean/cleanup as noted in this ticket. I also can not get uninstall to work either. I would hazard a guess it has the same issues that cleanup does. Any ETA when this will be set right? I'm starting a new project and would like to get my house in order. Also I have GEM_HOME=/Library/Ruby/Gems/1.8 set in my shell Thanks in advance John gems$ pwd /Library/Ruby/Gems/1.8/gems gems$ gems$ gems$ ls merb-core* merb-core-1.0.7.1: CHANGELOG LICENSE README TODO lib CONTRIBUTORS PUBLIC_CHANGELOG Rakefile bin merb-core-1.0.8: CHANGELOG LICENSE README TODO lib CONTRIBUTORS PUBLIC_CHANGELOG Rakefile bin merb-core-1.0.8.1: CHANGELOG LICENSE README TODO lib CONTRIBUTORS PUBLIC_CHANGELOG Rakefile bin gems$ gems$ gems$ sudo gem uninstall --version '= 1.0.7.1' merb-core --debug Exception `NameError' at /Library/Ruby/Site/1.8/rubygems/command_manager.rb:134 - uninitialized constant Gem::Commands::UninstallCommand Exception `Gem::InstallError' at /Library/Ruby/Site/1.8/rubygems/uninstaller.rb:61 - Unknown gem merb-core = 1.0.7.1 ERROR: While executing gem ... (Gem::InstallError) Unknown gem merb-core = 1.0.7.1 /Library/Ruby/Site/1.8/rubygems/uninstaller.rb:61:in `uninstall' /Library/Ruby/Site/1.8/rubygems/commands/uninstall_command.rb:63:in `execute' /Library/Ruby/Site/1.8/rubygems/commands/uninstall_command.rb:61:in `each' /Library/Ruby/Site/1.8/rubygems/commands/uninstall_command.rb:61:in `execute' /Library/Ruby/Site/1.8/rubygems/command.rb:136:in `invoke' /Library/Ruby/Site/1.8/rubygems/command_manager.rb:105:in `process_args' /Library/Ruby/Site/1.8/rubygems/command_manager.rb:75:in `run' /Library/Ruby/Site/1.8/rubygems/gem_runner.rb:39:in `run' /usr/bin/gem:24 gems$ gems$ gems$ gems$ gems$ cat ~/.gemrc --- :verbose: true :benchmark: false :sources: - http://edge.merbivore.com - http://gems.rubyforge.org/ :update_sources: true :backtrace: false :bulk_threshold: 1000 gems$ gems$ gems$ gems$ gem env RubyGems Environment: - RUBYGEMS VERSION: 1.3.1 - RUBY VERSION: 1.8.6 (2008-03-03 patchlevel 114) [universal-darwin9.0] - INSTALLATION DIRECTORY: /Library/Ruby/Gems/1.8 - RUBY EXECUTABLE: /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/ruby - EXECUTABLE DIRECTORY: /usr/bin - RUBYGEMS PLATFORMS: - ruby - universal-darwin-9 - GEM PATHS: - /Library/Ruby/Gems/1.8 - /Users/johnstehle/.gem/ruby/1.8 - /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/gems/1.8 - GEM CONFIGURATION: - :update_sources => true - :verbose => true - :benchmark => false - :backtrace => false - :bulk_threshold => 1000 - :sources => ["http://edge.merbivore.com", "http://gems.rubyforge.org/"] - REMOTE SOURCES: - http://edge.merbivore.com - http://gems.rubyforge.org/ gems$ gems$ gems$ ---------------------------------------------------------------------- Comment By: Daniel Berger (djberg96) Date: 2009-01-04 16:24 Message: Grr, the logic should be: if @options[:install_dir] paths = [@options[:install_dir]] else paths = Gem.path.uniq end paths.each do |path| path = File.expand_path(path) spec_dir = File.join(path, 'specifications') unless File.exists?(spec_dir) raise ArgumentError, "path '#{spec_dir}' not found" end source_index = Gem::SourceIndex.from_gems_in(spec_dir) list = source_index.find_name(@gem, @version) ... ---------------------------------------------------------------------- Comment By: Daniel Berger (djberg96) Date: 2009-01-04 16:23 Message: Whoops, the logic should be: paths.each do |path| path = File.expand_path(path) spec_dir = File.join(path, 'specifications') ---------------------------------------------------------------------- Comment By: Daniel Berger (djberg96) Date: 2009-01-04 16:21 Message: Alright, digging through this some more has revealed some deeper fundamental issues. But, let's step back to the immediate fix. The first thing to to is to add a '-i' option to cleanup_command.rb. Not only is it more convenient, it eliminates the need to hard code the install_dir in the super call. That's something we don't want hard coded. The next thing to do is to modify uninstaller.rb so that it iterates over Gem.path, unless the -i option is specified, in which case _only_ that path will be cleaned. Previously it was defaulting to a hard coded install_dir, which was set to Gem.dir. So, our logic for the uninstall method looked something like this: paths.each do |path| if @options[:install_dir] paths = [@options[:install_dir]] else paths = Gem.path.uniq end path = File.expand_path(path) spec_dir = File.join(path, 'specifications') unless File.exists?(spec_dir) raise ArgumentError, "path '#{spec_dir}' not found" end source_index = Gem::SourceIndex.from_gems_in(spec_dir) list = source_index.find_name(@gem, @version) ... Unfortunately, what I've discovered is that the dependency list (in dependency_list.rb) once again only checks in Gem.dir, not every Gem.path, causing it to blow up with: Exception `NoMethodError' at C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/dependency_list.rb:86 - undefined method `name' for nil:NilClass ERROR: While executing gem ... (NoMethodError) undefined method `name' for nil:NilClass C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/dependency_list.rb:86:in `ok_to_remove?' C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:91:in `find_all' C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/dependency_list.rb:85:in `each' C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/dependency_list.rb:85:in `find_all' C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/dependency_list.rb:85:in `ok_to_remove?' C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/uninstaller.rb:242:in `dependencies_ok?' C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/uninstaller.rb:185:in `remove' C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/uninstaller.rb:113:in `uninstall_gem' C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/uninstaller.rb:97:in `uninstall' C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/uninstaller.rb:66:in `each' C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/uninstaller.rb:66:in `uninstall' C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/commands/cleanup_command.rb:83:in `execute' C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/commands/cleanup_command.rb:70:in `each' C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/commands/cleanup_command.rb:70:in `execute' C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/command.rb:136:in `invoke' C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/command_manager.rb:105:in `process_args' C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/command_manager.rb:75:in `run' C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/gem_runner.rb:39:in `run' C:/Ruby/bin/gem:24 Still working on it. ---------------------------------------------------------------------- Comment By: Daniel Berger (djberg96) Date: 2009-01-04 15:11 Message: My initial attempt to just return if not found didn't work. I tried this in uninstaller.rb: if list.empty? then return But, it never seems to actually clean the gem, though it gives the impression that it did: c:\staging\gems>gem clean Cleaning up installed gems... Attempting to uninstall ptools-1.1.5 Clean Up Complete c:\staging\gems>gem clean Cleaning up installed gems... Attempting to uninstall ptools-1.1.5 Clean Up Complete Still working on it. ---------------------------------------------------------------------- Comment By: Daniel Berger (djberg96) Date: 2009-01-04 14:52 Message: I'm able to duplicate this on my Windows box. This demonstrates the problem: set GEM_PATH=c:\staging gem install ptools -i c:\staging gem install ptools --version=1.1.5 -i c:\staging gem clean Exception `Gem::InstallError' at C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/uninstaller.rb:61 - Unknown gem ptools = 1.1.5 ERROR: While executing gem ... (Gem::InstallError) Unknown gem ptools = 1.1.5 C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/uninstaller.rb:61:in `uninstall' C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/commands/cleanup_command.rb:78:in `execute' C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/commands/cleanup_command.rb:65:in `each' C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/commands/cleanup_command.rb:65:in `execute' C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/command.rb:136:in `invoke' C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/command_manager.rb:105:in `process_args' C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/command_manager.rb:75:in `run' C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/gem_runner.rb:39:in `run' C:/Ruby/bin/gem:24 The problem is that 'gem clean' is detecting that there's an older gem in one of my gem paths, but it proceeds to assume that it's in _every_ gem path. When it can't find it in one of the other paths it blows up. Working on it... ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=22770&group_id=126 From noreply at rubyforge.org Sun May 9 04:23:10 2010 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 9 May 2010 04:23:10 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-27087 ] Rubygems 1.3.5 and Ruby 1.9 breaks hard after require 'rubygems/specification' Message-ID: <20100509082311.175D91858329@rubyforge.org> Bugs item #27087, was opened at 2009-09-10 20:34 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27087&group_id=126 Category: #gem and #require methods Group: None Status: Open Resolution: None Priority: 1 Submitted By: Rob Sanheim (rsanheim) Assigned to: Eric Hodel (drbrain) Summary: Rubygems 1.3.5 and Ruby 1.9 breaks hard after require 'rubygems/specification' Initial Comment: Please see the repo: http://github.com/rsanheim/ruby19_rubygems_bug/tree/master The build is here: http://runcoderun.com/rsanheim/ruby19_rubygems_bug The failing build on Ruby 1.9.1 p243: http://runcoderun.com/rsanheim/ruby19_rubygems_bug http://runcoderun.com/rsanheim/ruby19_rubygems_bug/builds/09a9f683fe7848980e10ac7bd2291040ec11ea17/1/ruby_191 Here is the simplest code to illustrate: require 'hoe' gem 'hoe' # these should work puts "about to break 'gem'" require 'rubygems/specification' gem 'hoe' # exception thrown here when it shouldn't be ---------------------------------------------------------------------- Comment By: Hedge Hog (hedgehog) Date: 2010-05-09 08:23 Message: OK, disregard last comment. Some other gems need to be installed. Recommended workaround is as mentioned before: Remove require 'rubygems/specification' So far I have not seen any adverse side effects. ---------------------------------------------------------------------- Comment By: Hedge Hog (hedgehog) Date: 2010-05-09 04:23 Message: Why I'm not yet sure but it is called after rake/gempackagetask. Specifically: require 'rubygems' require 'rake/gempackagetask' require 'rubygems/specification' If I comment out the require 'rubygems/specification' I still get a failure: http://www.pastie.org/952149 I'm yet to get my head around how/why Chef has to use this sequence.... they may not be alone. It is still a useful example of a reproducible case that is minimal: $ gem list --local *** LOCAL GEMS *** rake (0.8.7) rdoc (2.5.8) HTH? ---------------------------------------------------------------------- Comment By: Eric Hodel (drbrain) Date: 2010-05-04 20:26 Message: Why are you requiring rubygems/specification? require 'rubygems' provides it for you. ---------------------------------------------------------------------- Comment By: Hedge Hog (hedgehog) Date: 2010-05-04 05:49 Message: The following is a minimal rvm example, the `rake -T` command triggers the issue here too: bash < <( curl http://rvm.beginrescueend.com/releases/rvm-install-head ) cat >~/.bash_profile <&1|tee /tmp/rake-t-error.log popd popd The rake log is here: http://www.pastie.org/944745 HTH? gem list --local *** LOCAL GEMS *** rake (0.8.7) rdoc (2.5.8) ---------------------------------------------------------------------- Comment By: Hedge Hog (hedgehog) Date: 2010-05-04 04:39 Message: Also affects: ruby 1.9.2dev (2009-07-18 trunk 24186) [x86_64-linux] ---------------------------------------------------------------------- Comment By: Eric Hodel (drbrain) Date: 2010-04-22 03:54 Message: I'm not entirely sure how this is breaking, but require 'rubygems' provides Gem::Specification, so you don't need to require it. The workaround is to not require 'rubygems/specification'. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2009-09-11 07:30 Message: We've already tracked down the problem. The workaround as described is to remove your manually installed rubygems from 1.9.x. ---------------------------------------------------------------------- Comment By: Adam Salter (aqsalter) Date: 2009-09-11 06:33 Message: Ryan: Sorry about that. I (too) am working on several projects, busy and wanted to throw in my helpful comments... I find problems can get fixed quicker if the devs know how many people are affected. I misunderstood your initial comment: '0 failures out of 4' sounds like no failures, which could certainly be assumed to be a good thing - except we are trying to track down a problem. +1 biting off a much ruder comment and looking to the future with hope and optimism. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2009-09-11 06:08 Message: Please don't +1. That shit is obnoxious. We don't need to test this against jeweler if we have a much cleaner smaller repro that is standalone. ---------------------------------------------------------------------- Comment By: Adam Salter (aqsalter) Date: 2009-09-11 01:47 Message: +1 please fix... Not exactly 'urgent' but annoying. I raised a bug on the 'jeweler' gem because of this: http://github.com/technicalpickles/jeweler/issues#issue/34 I'm sure that the code i provide there: Rakefile: require 'jeweler' rake -T will trigger issue. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2009-09-10 20:54 Message: Huh! % sudo gem uninstall rubygems-update % multiruby -rubygems -rrubygems/specification -e 'gem "hoe"' ... TOTAL RESULT = 0 failures out of 4 Passed: 1.9.1-p129, 1.8.7-p72, 1.8.7-p160, 1.8.6-p368 ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2009-09-10 20:53 Message: Easier repro of the warnings: multiruby -rubygems -rrubygems/specification -e 0 and: multiruby -rubygems -rrubygems/specification -e 'gem "hoe"' ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27087&group_id=126 From luislavena at gmail.com Sun May 9 13:44:33 2010 From: luislavena at gmail.com (Luis Lavena) Date: Sun, 9 May 2010 14:44:33 -0300 Subject: [Rubygems-developers] 1.3.7 ok to release? In-Reply-To: References: <7618A6D4-E0EF-49FE-813E-4F17D0ABE314@zenspider.com> Message-ID: On Mon, May 3, 2010 at 5:13 PM, Eric Hodel wrote: > On May 3, 2010, at 08:08, Luis Lavena wrote: >> Since 1.9.2 is deprecating YAML.quick_emit, I think 1.3.7 should go >> out with a fix for that in specification.rb >> >> Eric: what do you think? > > Aaron (author of Psych) gave me a patch that handles this correctly for both Syck and Psych, so 1.3.7 is forward and backward compatible. Eric, has this patch been applied to trunk of rubygems? I'm testing and using rubygems trunk in my Ruby projects today and want to know if I'm missing something for turning 1.3.7 a reality. Thank you. -- Luis Lavena AREA 17 - Perfection in design is achieved not when there is nothing more to add, but rather when there is nothing more to take away. Antoine de Saint-Exup?ry From drbrain at segment7.net Mon May 10 19:06:43 2010 From: drbrain at segment7.net (Eric Hodel) Date: Mon, 10 May 2010 16:06:43 -0700 Subject: [Rubygems-developers] 1.3.7 ok to release? In-Reply-To: References: <7618A6D4-E0EF-49FE-813E-4F17D0ABE314@zenspider.com> Message-ID: <317AFBC9-069F-4A8B-BBC3-3C5DAB366D49@segment7.net> On May 9, 2010, at 10:44, Luis Lavena wrote: > On Mon, May 3, 2010 at 5:13 PM, Eric Hodel wrote: >> On May 3, 2010, at 08:08, Luis Lavena wrote: >>> Since 1.9.2 is deprecating YAML.quick_emit, I think 1.3.7 should go >>> out with a fix for that in specification.rb >>> >>> Eric: what do you think? >> >> Aaron (author of Psych) gave me a patch that handles this correctly for both Syck and Psych, so 1.3.7 is forward and backward compatible. > > Eric, has this patch been applied to trunk of rubygems? > > I'm testing and using rubygems trunk in my Ruby projects today and > want to know if I'm missing something for turning 1.3.7 a reality. The patch is applied on both RubyGems trunk and Ruby trunk. From drbrain at segment7.net Fri May 14 00:53:00 2010 From: drbrain at segment7.net (Eric Hodel) Date: Thu, 13 May 2010 21:53:00 -0700 Subject: [Rubygems-developers] [ANN] RubyGems 1.3.7 Message-ID: rubygems version 1.3.7 has been released! * * * * RubyGems is a package management framework for Ruby. This gem is an update for the RubyGems software. You must have an installation of RubyGems before this update can be applied. See Gem for information on RubyGems (or `ri Gem`) To upgrade to the latest RubyGems, run: $ gem update --system # you might need to be an administrator or root NOTE: RubyGems 1.1 and 1.2 have problems upgrading when there is no rubygems-update installed. You will need to use the following instructions if you see "Nothing to update". If you have an older version of RubyGems installed, then you can still do it in two steps: $ gem install rubygems-update # again, might need to be admin/root $ update_rubygems # ... here too If you don't have any RubyGems install, there is still the pre-gem approach to getting software, doing it manually: 1. Download from: http://rubyforge.org/frs/?group_id=126 2. Unpack into a directory and cd there 3. Install with: ruby setup.rb # you may need admin/root privilege For more details and other options, see: ruby setup.rb --help Changes: ### 1.3.7 / 2010-05-13 NOTE: http://rubygems.org is now the default source for downloading gems. You may have sources set via ~/.gemrc, so you should replace http://gems.rubyforge.org with http://rubygems.org http://gems.rubyforge.org will continue to work for the forseeable future. New features: * `gem` commands * `gem install` and `gem fetch` now report alternate platforms when a matching one couldn't be found. * `gem contents` --prefix is now the default as specified in --help. Bug #27211 by Mamoru Tasaka. * `gem fetch` can fetch of old versions again. Bug #27960 by Eric Hankins. * `gem query` and friends output now lists platforms. Bug #27856 by Greg Hazel. * `gem server` now allows specification of multiple gem dirs for documentation. Bug #27573 by Yuki Sonoda. * `gem unpack` can unpack gems again. Bug #27872 by Timothy Jones. * `gem unpack` now unpacks remote gems. * --user-install is no longer the default. If you really liked it, see Gem::ConfigFile to learn how to set it by default. (This change was made in 1.3.6) * RubyGems now has platform support for IronRuby. Patch #27951 by Will Green. Bug fixes: * Require rubygems/custom_require if --disable-gem was set. Bug #27700 by Roger Pack. * RubyGems now protects against exceptions being raised by plugins. * rubygems/builder now requires user_interaction. Ruby Bug #1040 by Phillip Toland. * Gem::Dependency support #version_requirements= with a warning. Fix for old Rails versions. Bug #27868 by Wei Jen Lu. * Gem::PackageTask depends on the package dir like the other rake package tasks so dependencies can be hooked up correctly. From noreply at rubyforge.org Tue May 18 11:36:23 2010 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 18 May 2010 11:36:23 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-28212 ] UndefinedConversionError if Encoding.default_internal=ASCII-8BIT Message-ID: <20100518153623.B4D0318582EE@rubyforge.org> Bugs item #28212, was opened at 2010-05-18 15:36 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28212&group_id=126 Category: #gem and #require methods Group: None Status: Open Resolution: None Priority: 3 Submitted By: Mike Smith (msmith177) Assigned to: Nobody (None) Summary: UndefinedConversionError if Encoding.default_internal=ASCII-8BIT Initial Comment: With ruby 1.9.1, the default internal string encoding can be set with Encoding.default_internal= or by passing ruby the -E":US-ASCII" option. If the internal encoding is set to non-UTF-8 encodings such as US-ASCII, BINARY, or ISO-8859-1, then you will get an exception when trying to load rubygems if you have installed gemspecs that have non-ASCII characters. ==== To reproduce ==== * Install Nokogiri, or any other gem that has non-ascii characters in its gemspec. * Run test.rb (attached) ==== Exception ==== $ ruby test.rb Encoding.default_internal = US-ASCII /opt/local/lib/ruby1.9/site_ruby/1.9.1/rubygems/source_index.rb:89:in `read': "\xE9\x8B\xB8" from UTF-8 to US-ASCII (Encoding::UndefinedConversionError) from /opt/local/lib/ruby1.9/site_ruby/1.9.1/rubygems/source_index.rb:89:in `load_specification' from /opt/local/lib/ruby1.9/site_ruby/1.9.1/rubygems/source_index.rb:153:in `block (2 levels) in load_gems_in' from /opt/local/lib/ruby1.9/site_ruby/1.9.1/rubygems/source_index.rb:152:in `each' from /opt/local/lib/ruby1.9/site_ruby/1.9.1/rubygems/source_index.rb:152:in `block in load_gems_in' from /opt/local/lib/ruby1.9/site_ruby/1.9.1/rubygems/source_index.rb:149:in `reverse_each' from /opt/local/lib/ruby1.9/site_ruby/1.9.1/rubygems/source_index.rb:149:in `load_gems_in' from /opt/local/lib/ruby1.9/site_ruby/1.9.1/rubygems/source_index.rb:345:in `refresh!' from /opt/local/lib/ruby1.9/site_ruby/1.9.1/rubygems/source_index.rb:78:in `from_gems_in' from /opt/local/lib/ruby1.9/site_ruby/1.9.1/rubygems/source_index.rb:58:in `from_installed_gems' from /opt/local/lib/ruby1.9/site_ruby/1.9.1/rubygems.rb:883:in `source_index' from /opt/local/lib/ruby1.9/site_ruby/1.9.1/rubygems/gem_path_searcher.rb:81:in `init_gemspecs' from /opt/local/lib/ruby1.9/site_ruby/1.9.1/rubygems/gem_path_searcher.rb:13:in `initialize' from /opt/local/lib/ruby1.9/site_ruby/1.9.1/rubygems.rb:841:in `new' from /opt/local/lib/ruby1.9/site_ruby/1.9.1/rubygems.rb:841:in `block in searcher' from :8:in `synchronize' from /opt/local/lib/ruby1.9/site_ruby/1.9.1/rubygems.rb:840:in `searcher' from /opt/local/lib/ruby1.9/site_ruby/1.9.1/rubygems.rb:479:in `find_files' from /opt/local/lib/ruby1.9/site_ruby/1.9.1/rubygems.rb:983:in `load_plugins' from /opt/local/lib/ruby1.9/site_ruby/1.9.1/rubygems.rb:1139:in `' from :235:in `require' from :235:in `load_full_rubygems_library' from :334:in `const_missing' from test.rb:12:in `
' ==== Suggested fix ==== Always specify the internal encoding as UTF-8 when reading gemspec files. Don't use the default internal encoding. (see attached patch) ==== My environment ==== $ gem env RubyGems Environment: - RUBYGEMS VERSION: 1.3.7 - RUBY VERSION: 1.9.1 (2010-01-10 patchlevel 378) [i386-darwin10] - INSTALLATION DIRECTORY: /opt/local/lib/ruby/gems/1.9.1 - RUBY EXECUTABLE: /opt/local/bin/ruby1.9 - EXECUTABLE DIRECTORY: /opt/local/bin - RUBYGEMS PLATFORMS: - ruby - x86-darwin-10 - GEM PATHS: - /opt/local/lib/ruby/gems/1.9.1 - /Users/msmith/.gem/ruby/1.9.1 - GEM CONFIGURATION: - :update_sources => true - :verbose => true - :benchmark => false - :backtrace => false - :bulk_threshold => 1000 - REMOTE SOURCES: - http://rubygems.org/ ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28212&group_id=126 From noreply at rubyforge.org Tue May 18 11:54:50 2010 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 18 May 2010 11:54:50 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-28212 ] UndefinedConversionError if Encoding.default_internal=ASCII-8BIT Message-ID: <20100518155450.8280E16782AB@rubyforge.org> Bugs item #28212, was opened at 2010-05-18 10:36 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28212&group_id=126 Category: #gem and #require methods Group: None Status: Open Resolution: None Priority: 3 Submitted By: Mike Smith (msmith177) Assigned to: Nobody (None) Summary: UndefinedConversionError if Encoding.default_internal=ASCII-8BIT Initial Comment: With ruby 1.9.1, the default internal string encoding can be set with Encoding.default_internal= or by passing ruby the -E":US-ASCII" option. If the internal encoding is set to non-UTF-8 encodings such as US-ASCII, BINARY, or ISO-8859-1, then you will get an exception when trying to load rubygems if you have installed gemspecs that have non-ASCII characters. ==== To reproduce ==== * Install Nokogiri, or any other gem that has non-ascii characters in its gemspec. * Run test.rb (attached) ==== Exception ==== $ ruby test.rb Encoding.default_internal = US-ASCII /opt/local/lib/ruby1.9/site_ruby/1.9.1/rubygems/source_index.rb:89:in `read': "\xE9\x8B\xB8" from UTF-8 to US-ASCII (Encoding::UndefinedConversionError) from /opt/local/lib/ruby1.9/site_ruby/1.9.1/rubygems/source_index.rb:89:in `load_specification' from /opt/local/lib/ruby1.9/site_ruby/1.9.1/rubygems/source_index.rb:153:in `block (2 levels) in load_gems_in' from /opt/local/lib/ruby1.9/site_ruby/1.9.1/rubygems/source_index.rb:152:in `each' from /opt/local/lib/ruby1.9/site_ruby/1.9.1/rubygems/source_index.rb:152:in `block in load_gems_in' from /opt/local/lib/ruby1.9/site_ruby/1.9.1/rubygems/source_index.rb:149:in `reverse_each' from /opt/local/lib/ruby1.9/site_ruby/1.9.1/rubygems/source_index.rb:149:in `load_gems_in' from /opt/local/lib/ruby1.9/site_ruby/1.9.1/rubygems/source_index.rb:345:in `refresh!' from /opt/local/lib/ruby1.9/site_ruby/1.9.1/rubygems/source_index.rb:78:in `from_gems_in' from /opt/local/lib/ruby1.9/site_ruby/1.9.1/rubygems/source_index.rb:58:in `from_installed_gems' from /opt/local/lib/ruby1.9/site_ruby/1.9.1/rubygems.rb:883:in `source_index' from /opt/local/lib/ruby1.9/site_ruby/1.9.1/rubygems/gem_path_searcher.rb:81:in `init_gemspecs' from /opt/local/lib/ruby1.9/site_ruby/1.9.1/rubygems/gem_path_searcher.rb:13:in `initialize' from /opt/local/lib/ruby1.9/site_ruby/1.9.1/rubygems.rb:841:in `new' from /opt/local/lib/ruby1.9/site_ruby/1.9.1/rubygems.rb:841:in `block in searcher' from :8:in `synchronize' from /opt/local/lib/ruby1.9/site_ruby/1.9.1/rubygems.rb:840:in `searcher' from /opt/local/lib/ruby1.9/site_ruby/1.9.1/rubygems.rb:479:in `find_files' from /opt/local/lib/ruby1.9/site_ruby/1.9.1/rubygems.rb:983:in `load_plugins' from /opt/local/lib/ruby1.9/site_ruby/1.9.1/rubygems.rb:1139:in `' from :235:in `require' from :235:in `load_full_rubygems_library' from :334:in `const_missing' from test.rb:12:in `
' ==== Suggested fix ==== Always specify the internal encoding as UTF-8 when reading gemspec files. Don't use the default internal encoding. (see attached patch) ==== My environment ==== $ gem env RubyGems Environment: - RUBYGEMS VERSION: 1.3.7 - RUBY VERSION: 1.9.1 (2010-01-10 patchlevel 378) [i386-darwin10] - INSTALLATION DIRECTORY: /opt/local/lib/ruby/gems/1.9.1 - RUBY EXECUTABLE: /opt/local/bin/ruby1.9 - EXECUTABLE DIRECTORY: /opt/local/bin - RUBYGEMS PLATFORMS: - ruby - x86-darwin-10 - GEM PATHS: - /opt/local/lib/ruby/gems/1.9.1 - /Users/msmith/.gem/ruby/1.9.1 - GEM CONFIGURATION: - :update_sources => true - :verbose => true - :benchmark => false - :backtrace => false - :bulk_threshold => 1000 - REMOTE SOURCES: - http://rubygems.org/ ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28212&group_id=126 From noreply at rubyforge.org Tue May 18 11:57:06 2010 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 18 May 2010 11:57:06 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-28212 ] UndefinedConversionError if Encoding.default_internal=ASCII-8BIT Message-ID: <20100518155706.71C1B16782AB@rubyforge.org> Bugs item #28212, was opened at 2010-05-18 10:36 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28212&group_id=126 Category: #gem and #require methods Group: None Status: Open Resolution: None Priority: 3 Submitted By: Mike Smith (msmith177) Assigned to: Nobody (None) Summary: UndefinedConversionError if Encoding.default_internal=ASCII-8BIT Initial Comment: With ruby 1.9.1, the default internal string encoding can be set with Encoding.default_internal= or by passing ruby the -E":US-ASCII" option. If the internal encoding is set to non-UTF-8 encodings such as US-ASCII, BINARY, or ISO-8859-1, then you will get an exception when trying to load rubygems if you have installed gemspecs that have non-ASCII characters. ==== To reproduce ==== * Install Nokogiri, or any other gem that has non-ascii characters in its gemspec. * Run test.rb (attached) ==== Exception ==== $ ruby test.rb Encoding.default_internal = US-ASCII /opt/local/lib/ruby1.9/site_ruby/1.9.1/rubygems/source_index.rb:89:in `read': "\xE9\x8B\xB8" from UTF-8 to US-ASCII (Encoding::UndefinedConversionError) from /opt/local/lib/ruby1.9/site_ruby/1.9.1/rubygems/source_index.rb:89:in `load_specification' from /opt/local/lib/ruby1.9/site_ruby/1.9.1/rubygems/source_index.rb:153:in `block (2 levels) in load_gems_in' from /opt/local/lib/ruby1.9/site_ruby/1.9.1/rubygems/source_index.rb:152:in `each' from /opt/local/lib/ruby1.9/site_ruby/1.9.1/rubygems/source_index.rb:152:in `block in load_gems_in' from /opt/local/lib/ruby1.9/site_ruby/1.9.1/rubygems/source_index.rb:149:in `reverse_each' from /opt/local/lib/ruby1.9/site_ruby/1.9.1/rubygems/source_index.rb:149:in `load_gems_in' from /opt/local/lib/ruby1.9/site_ruby/1.9.1/rubygems/source_index.rb:345:in `refresh!' from /opt/local/lib/ruby1.9/site_ruby/1.9.1/rubygems/source_index.rb:78:in `from_gems_in' from /opt/local/lib/ruby1.9/site_ruby/1.9.1/rubygems/source_index.rb:58:in `from_installed_gems' from /opt/local/lib/ruby1.9/site_ruby/1.9.1/rubygems.rb:883:in `source_index' from /opt/local/lib/ruby1.9/site_ruby/1.9.1/rubygems/gem_path_searcher.rb:81:in `init_gemspecs' from /opt/local/lib/ruby1.9/site_ruby/1.9.1/rubygems/gem_path_searcher.rb:13:in `initialize' from /opt/local/lib/ruby1.9/site_ruby/1.9.1/rubygems.rb:841:in `new' from /opt/local/lib/ruby1.9/site_ruby/1.9.1/rubygems.rb:841:in `block in searcher' from :8:in `synchronize' from /opt/local/lib/ruby1.9/site_ruby/1.9.1/rubygems.rb:840:in `searcher' from /opt/local/lib/ruby1.9/site_ruby/1.9.1/rubygems.rb:479:in `find_files' from /opt/local/lib/ruby1.9/site_ruby/1.9.1/rubygems.rb:983:in `load_plugins' from /opt/local/lib/ruby1.9/site_ruby/1.9.1/rubygems.rb:1139:in `' from :235:in `require' from :235:in `load_full_rubygems_library' from :334:in `const_missing' from test.rb:12:in `
' ==== Suggested fix ==== Always specify the internal encoding as UTF-8 when reading gemspec files. Don't use the default internal encoding. (see attached patch) ==== My environment ==== $ gem env RubyGems Environment: - RUBYGEMS VERSION: 1.3.7 - RUBY VERSION: 1.9.1 (2010-01-10 patchlevel 378) [i386-darwin10] - INSTALLATION DIRECTORY: /opt/local/lib/ruby/gems/1.9.1 - RUBY EXECUTABLE: /opt/local/bin/ruby1.9 - EXECUTABLE DIRECTORY: /opt/local/bin - RUBYGEMS PLATFORMS: - ruby - x86-darwin-10 - GEM PATHS: - /opt/local/lib/ruby/gems/1.9.1 - /Users/msmith/.gem/ruby/1.9.1 - GEM CONFIGURATION: - :update_sources => true - :verbose => true - :benchmark => false - :backtrace => false - :bulk_threshold => 1000 - REMOTE SOURCES: - http://rubygems.org/ ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28212&group_id=126 From transfire at gmail.com Tue May 18 18:50:43 2010 From: transfire at gmail.com (Trans) Date: Tue, 18 May 2010 15:50:43 -0700 (PDT) Subject: [Rubygems-developers] Ruby Implementation Gems? Message-ID: I know about platform gems. But can RubyGems differentiate a jruby gem from, say, an mri gem? What about an mri 1.8 from a 1.9? Or is there only supposed to one gem that handle these distinctions internally? Personally I like the later notion, but I need to understand if RubyGems can distinguish them in the sense that it distinguishes platform gems. From luislavena at gmail.com Wed May 19 10:55:08 2010 From: luislavena at gmail.com (Luis Lavena) Date: Wed, 19 May 2010 11:55:08 -0300 Subject: [Rubygems-developers] Ruby Implementation Gems? In-Reply-To: References: Message-ID: On Tue, May 18, 2010 at 7:50 PM, Trans wrote: > I know about platform gems. But can RubyGems differentiate a jruby gem > from, say, an mri gem? What about an mri 1.8 from a 1.9? Or is there > only supposed to one gem that handle these distinctions internally? > I've raised this question not long ago: http://rubyforge.org/pipermail/rubygems-developers/2009-April/004522.html For a project I'm working now, using the platform I can separate mri/java and now ironruby gems. But of course, I cannot individualize Ruby versions, so I ended doing that in the code. > Personally I like the later notion, but I need to understand if > RubyGems can distinguish them in the sense that it distinguishes > platform gems. Not at this time, and highly unlikely is going to happen, as that will require change in the Specification, indexing and fetching mechanisms, which if you read the above thread, will see not going to happen. -- Luis Lavena AREA 17 - Perfection in design is achieved not when there is nothing more to add, but rather when there is nothing more to take away. Antoine de Saint-Exup?ry From rick.denatale at gmail.com Wed May 19 11:24:51 2010 From: rick.denatale at gmail.com (Rick DeNatale) Date: Wed, 19 May 2010 11:24:51 -0400 Subject: [Rubygems-developers] Ruby Implementation Gems? In-Reply-To: References: Message-ID: On Wed, May 19, 2010 at 10:55 AM, Luis Lavena wrote: > On Tue, May 18, 2010 at 7:50 PM, Trans wrote: >> I know about platform gems. But can RubyGems differentiate a jruby gem >> from, say, an mri gem? What about an mri 1.8 from a 1.9? Or is there >> only supposed to one gem that handle these distinctions internally? >> > > I've raised this question not long ago: > > http://rubyforge.org/pipermail/rubygems-developers/2009-April/004522.html > > For a project I'm working now, using the platform I can separate > mri/java and now ironruby gems. > > But of course, I cannot individualize Ruby versions, so I ended doing > that in the code. > >> Personally I like the later notion, but I need to understand if >> RubyGems can distinguish them in the sense that it distinguishes >> platform gems. > > Not at this time, and highly unlikely is going to happen, as that will > require change in the Specification, indexing and fetching mechanisms, > which if you read the above thread, will see not going to happen. Well rubygems can't do it by it self, but for POSIX systems supporting bash or zsh at least RVM allows very fine-grained control over gemsets, not just for different Ruby implementations, but for different versions, and even for individual projects. http://rvm.beginrescueend.com/ With apologies to Luis, I don't think this helps Windows users. Perhaps it might inspire a windows solution though for those who want that. -- Rick DeNatale Blog: http://talklikeaduck.denhaven2.com/ Github: http://github.com/rubyredrick Twitter: @RickDeNatale WWR: http://www.workingwithrails.com/person/9021-rick-denatale LinkedIn: http://www.linkedin.com/in/rickdenatale From luislavena at gmail.com Wed May 19 11:33:25 2010 From: luislavena at gmail.com (Luis Lavena) Date: Wed, 19 May 2010 12:33:25 -0300 Subject: [Rubygems-developers] Ruby Implementation Gems? In-Reply-To: References: Message-ID: On Wed, May 19, 2010 at 12:24 PM, Rick DeNatale wrote: > [...] > > Well rubygems can't do it by it self, but for POSIX systems supporting > bash or zsh at least RVM allows very fine-grained control over > gemsets, not just for different Ruby implementations, but for > different versions, and even for individual projects. > > http://rvm.beginrescueend.com/ > RVM helps for development and testing, for sure, but do not help you putting the gem in the wild without preparation to be able to handle different Ruby versions, you can specify ~> to limit it to 1.8.x series, but you can't ship 2 gem versions, one for 1.8 and 1.9 differently. > With apologies to Luis, I don't think this helps Windows users. > Perhaps it might inspire a windows solution though for those who want > that. No need to apologize, there is the Windows equivalent: Pik: http://github.com/vertiginous/pik All my installed versions: >pik ls 100: IronRuby 1.0.0.0 on .NET 4.0.30319.1 141: jruby 1.4.1 (ruby 1.8.7 patchlevel 174) (2010-04-26 ea6db6a) (Java HotSpot(TM) Client VM 1.6.0_18) [x86-java] 150: jruby 1.5.0 (ruby 1.8.7 patchlevel 249) (2010-05-12 6769999) (Java HotSpot(TM) Client VM 1.6.0_18) [x86-java] 186: ruby 1.8.6 (2009-06-08 patchlevel 369) [i386-mswin32] 186: ruby 1.8.6 (2010-02-04 patchlevel 398) [i386-mingw32] * 187: ruby 1.8.7 (2009-12-24 patchlevel 248) [i386-mswin32] 187: ruby 1.8.7 (2010-01-10 patchlevel 249) [i386-mingw32] 191: ruby 1.9.1p376 (2009-12-07 revision 26041) [i386-mswin32] 191: ruby 1.9.1p378 (2010-01-10 revision 26273) [i386-mingw32] 192: ruby 1.9.2dev (2010-04-23 trunk 27453) [i386-mingw32] -- Luis Lavena AREA 17 - Perfection in design is achieved not when there is nothing more to add, but rather when there is nothing more to take away. Antoine de Saint-Exup?ry From jftucker at gmail.com Wed May 19 15:35:42 2010 From: jftucker at gmail.com (James Tucker) Date: Wed, 19 May 2010 16:35:42 -0300 Subject: [Rubygems-developers] Ruby Implementation Gems? In-Reply-To: References: Message-ID: On 19 May 2010, at 11:55, Luis Lavena wrote: > On Tue, May 18, 2010 at 7:50 PM, Trans wrote: >> I know about platform gems. But can RubyGems differentiate a jruby gem >> from, say, an mri gem? What about an mri 1.8 from a 1.9? Or is there >> only supposed to one gem that handle these distinctions internally? >> > > I've raised this question not long ago: > > http://rubyforge.org/pipermail/rubygems-developers/2009-April/004522.html > > For a project I'm working now, using the platform I can separate > mri/java and now ironruby gems. > > But of course, I cannot individualize Ruby versions, so I ended doing > that in the code. > >> Personally I like the later notion, but I need to understand if >> RubyGems can distinguish them in the sense that it distinguishes >> platform gems. > > Not at this time, and highly unlikely is going to happen, as that will > require change in the Specification, indexing and fetching mechanisms, > which if you read the above thread, will see not going to happen. This should be easier to move forward with since gemcutter, however, we have to address backward compatibility, I think we've had enough major changes in the last year that we should be careful with further major server side changes that could introduce either further backward compatibility issues, and/or increased support load for the team. Some of the old proposals could be problematic in this manner, although I still like their final goals, ofc. > > -- > Luis Lavena > AREA 17 > - > Perfection in design is achieved not when there is nothing more to add, > but rather when there is nothing more to take away. > Antoine de Saint-Exup?ry > _______________________________________________ > Rubygems-developers mailing list > http://rubyforge.org/projects/rubygems > Rubygems-developers at rubyforge.org > http://rubyforge.org/mailman/listinfo/rubygems-developers From noreply at rubyforge.org Thu May 20 16:42:28 2010 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 20 May 2010 16:42:28 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-28226 ] Gem::PackageTask gem_dir incorrect Message-ID: <20100520204228.38E341D799D9@rubyforge.org> Bugs item #28226, was opened at 2010-05-20 15:42 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28226&group_id=126 Category: other Group: v1.3.x Status: Open Resolution: None Priority: 3 Submitted By: Nick Sieger (nicksieger) Assigned to: Nobody (None) Summary: Gem::PackageTask gem_dir incorrect Initial Comment: The local variable "gem_dir" in Gem::PackageTask as added in r2471 incorrectly includes the platform (via gem_spec.full_name) when the parent is only expecting name-version. For gems that have platform names, this results in a bad rake prerequisite, since the actual directory is named without the '-java'. Don't know how to build task 'pkg/activerecord-jdbc-adapter-0.9.7-java' I think the intention is to just depend on the #package_dir_path name instead. Patch attached. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28226&group_id=126 From transfire at gmail.com Fri May 21 10:52:35 2010 From: transfire at gmail.com (Trans) Date: Fri, 21 May 2010 07:52:35 -0700 (PDT) Subject: [Rubygems-developers] Ruby Implementation Gems? In-Reply-To: References: Message-ID: <246cd597-1046-4f00-aed1-8122a99174c0@c11g2000vbe.googlegroups.com> On May 19, 3:35?pm, James Tucker wrote: > On 19 May 2010, at 11:55, Luis Lavena wrote: > > Not at this time, and highly unlikely is going to happen, as that will > > require change in the Specification, indexing and fetching mechanisms, > > which if you read the above thread, will see not going to happen. > > This should be easier to move forward with since gemcutter, however, we have to address backward compatibility, I think we've had enough major changes in the last year that we should be careful with further major server side changes that could introduce either further backward compatibility issues, and/or increased support load for the team. Some of the old proposals could be problematic in this manner, although I still like their final goals, ofc. Actually, I think it is better that way. With RubyGems I am not even sure why it bothers to divide gem install by ruby version, i.e. /usr/ lib/ruby/gems/1.8/ vs. /usr/lib/ruby/gems/1.9/. That kind of division made sense for setup.rb b/c installs would literally clobber each other there, but that is no longer the case with gems. So why bother? My feeling it that it is better to strive for universal packages, than it is to slice and dice a new gem for every platform variation. Not only does it make packaging easier, but I think it can contribute to keeping the various implementations in sync. That aside, perhaps someone can explain to me the relationship between RUBY_PLATFORM, RUBY_ENGINE and gem platform? From rick.denatale at gmail.com Fri May 21 11:23:53 2010 From: rick.denatale at gmail.com (Rick DeNatale) Date: Fri, 21 May 2010 11:23:53 -0400 Subject: [Rubygems-developers] Ruby Implementation Gems? In-Reply-To: <246cd597-1046-4f00-aed1-8122a99174c0@c11g2000vbe.googlegroups.com> References: <246cd597-1046-4f00-aed1-8122a99174c0@c11g2000vbe.googlegroups.com> Message-ID: On Fri, May 21, 2010 at 10:52 AM, Trans wrote: > Actually, I think it is better that way. With RubyGems I am not even > sure why it bothers to divide gem install by ruby version, i.e. /usr/ > lib/ruby/gems/1.8/ vs. /usr/lib/ruby/gems/1.9/. That kind of division > made sense for setup.rb b/c installs would literally clobber each > other there, but that is no longer the case with gems. So why bother? If there is a C extension in the gem, the Ruby extension API has some incompatibilities between 1.8.x and 1.9.x Also a gem which uses 1.9 Ruby syntax won't work on 1.8 either. -- Rick DeNatale Blog: http://talklikeaduck.denhaven2.com/ Github: http://github.com/rubyredrick Twitter: @RickDeNatale WWR: http://www.workingwithrails.com/person/9021-rick-denatale LinkedIn: http://www.linkedin.com/in/rickdenatale From jftucker at gmail.com Fri May 21 15:44:49 2010 From: jftucker at gmail.com (James Tucker) Date: Fri, 21 May 2010 16:44:49 -0300 Subject: [Rubygems-developers] Ruby Implementation Gems? In-Reply-To: References: <246cd597-1046-4f00-aed1-8122a99174c0@c11g2000vbe.googlegroups.com> Message-ID: On 21 May 2010, at 12:23, Rick DeNatale wrote: > On Fri, May 21, 2010 at 10:52 AM, Trans wrote: >> Actually, I think it is better that way. With RubyGems I am not even >> sure why it bothers to divide gem install by ruby version, i.e. /usr/ >> lib/ruby/gems/1.8/ vs. /usr/lib/ruby/gems/1.9/. That kind of division >> made sense for setup.rb b/c installs would literally clobber each >> other there, but that is no longer the case with gems. So why bother? > > If there is a C extension in the gem, the Ruby extension API has some > incompatibilities between 1.8.x and 1.9.x In fact, a C extension has to assurance to work even on the same version of the interpreter. You could have linked a different C runtime, you could have patched with REE, you could have different structs, etc, etc. We can't audit or manifest all of this detail (although it would be nice). There is some discussion on the rubyforge tracker on this topic already. It is absolutely critical for strict *correctness* (i.e. user reliability) that we not only version by a partial ruby version (1.8/1.9), but actually a full ruby version, including patch customisations, configuration details, and so on. Ideally each ruby install should have it's own unique identifier for the installation on the local system, and this value would be used to separate gems. An incomplete, poor example might be: ruby-1.8.7-p247-x86-mswin32-60, or ree+dtrace+mbari-1.8.7-p247-p12-x86-linux-gcc4.3.4-glibc2.10.1 I think it is important for a high level language with the design goals of ruby (human friendliness) that we don't deliberately implement solutions that may regularly lead to users having to dig into gdb in order to figure out what is going on. Rubyists care about ruby code, nothing lower level, and I think rubygems should continue to do what it can to make sure that this is the case, even if it may use more disk space. If you want to keep several gem sets in sync, well, you could very easily script up a new front end to the gem command to do this for you, and is something that any developer in the language should be able to do in absolutely minimal code, hell, you could just do it in sh(1). http://rubyforge.org/tracker/index.php?func=detail&aid=14943&group_id=126&atid=575 All food for thought... From thewoolleyman at gmail.com Sun May 23 04:21:46 2010 From: thewoolleyman at gmail.com (Chad Woolley) Date: Sun, 23 May 2010 01:21:46 -0700 Subject: [Rubygems-developers] API access to versions in list command Message-ID: This [1] manual Gem version parsing was just added to chef to handle the addition of platforms to the version string in 1.3.7. I had to update GemInstaller in a similar fashion [2]. Two questions: 1. Are we doing it wrong? Does the RubyGems API provide a way to avoid this manual parsing? 2. Should there be a --[no-]platforms option to the 'list' command, which would have made these updates to the parsing logic unnecessary? Thanks, -- Chad [1] http://github.com/opscode/chef/commit/b3b52ed426078098cc3daaabd04dda6e691ff252 [2] http://github.com/thewoolleyman/geminstaller/commit/97742ff3867ded49454c1ccfd9340e19fc53e351 From thewoolleyman at gmail.com Sun May 23 06:40:14 2010 From: thewoolleyman at gmail.com (Chad Woolley) Date: Sun, 23 May 2010 03:40:14 -0700 Subject: [Rubygems-developers] API access to versions in list command In-Reply-To: References: Message-ID: On Sun, May 23, 2010 at 1:21 AM, Chad Woolley wrote: > 1. Are we doing it wrong? Does the RubyGems API provide a way to avoid > this manual parsing? > 2. Should there be a --[no-]platforms option to the 'list' command, > which would have made these updates to the parsing logic unnecessary? So, I found Eric Hodel's admonishment "Why aren't you using the RubyGems API?" [1], but that's easier said than done. James Tucker followed with this example [2], but that doesn't help, because it isn't a remote call (just gives an array of "name-version" local entries). The only thing the API provides now is Gem.source_index for local gems, and Gem::SpecFetcher.fetcher for remote gems. Both of these return giant nested hashes and arrays of various nested values and objects. That's not too user-friendly or intuitive, which is why I think people just end up parsing the output of gem list. For example, here's the API call to see if a gem with the specified name_to_find, version_to_find, and platform_to_find exists remotely: name_to_find=/^json$/; version_to_find = '1.4.3'; platform_to_find='x86-mingw32'; Gem::SpecFetcher.fetcher.find_matching(Gem::Dependency.new(name_to_find,version_to_find),false,false).map{|spec_tuple| spec = spec_tuple.first; spec[2] == platform_to_find }.any?{|found| found == true} Is there something simpler? Maybe. I'm not sure. Like I said, not very intuitive, and looking at the RubyGems code for examples doesn't help much (e.g. the 225-line query_command#output_query_results) What are the problems? One problem is the lack of objects here. Returning a giant nested hash or array isn't a humane API. A second problem is the coupling of the version and platform concepts. Ideally, I'd like to have these abstractions: * A Gem has one or more Versions. * Each Version has one or more Platforms. Instead, SpecFetcher provides this representation of the platforms supported by a specific gem name and version: Gem::SpecFetcher.fetcher.find_matching(Gem::Dependency.new(/^json$/,'1.4.3'),true,false) [[["json", #, "x86-mingw32"], "http://rubygems.org/"], [["json", #, "ruby"], "http://rubygems.org/"], [["json", #, "x86-mswin32"], "http://rubygems.org/"]] What can we do? When I think of an "easy" API for this, it's kind of hard given these issues. Maybe we could at least provide something for the common use case chef and geminstaller had, which is "does this gem name (and optionally version/platform) exist remotely?" exists_remotely?(name, version=nil, platform=nil) where version and and platform would be defaulted to match anything. This method could be anywhere, on Gem, or a FriendlyApi module mixed into Gem; whatever as it is intuitive and easily found. Anyway, just some thoughts, because it's not cool to tell people "Use the API!" when that is only possible given a fairly deep understanding of RubyGems internals... -- Chad [1] https://tickets.opscode.com/browse/CHEF-1168?focusedCommentId=13981&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_13981 [2] https://tickets.opscode.com/browse/CHEF-1168?focusedCommentId=13983&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_13983 From noreply at rubyforge.org Sun May 23 13:58:52 2010 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 23 May 2010 13:58:52 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-28237 ] gem outdated fails for gems that are outdated but have a prerelease installed Message-ID: <20100523175852.7871A185835E@rubyforge.org> Bugs item #28237, was opened at 2010-05-23 14:58 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28237&group_id=126 Category: `gem` commands (other) Group: v1.3.x Status: Open Resolution: None Priority: 3 Submitted By: Caio Chassot (cchassot) Assigned to: Nobody (None) Summary: gem outdated fails for gems that are outdated but have a prerelease installed Initial Comment: $ sudo gem1.9 outdated --backtrace ERROR: While executing gem ... (NoMethodError) undefined method `first' for nil:NilClass .../rubygems/commands/outdated_command.rb:26:in `block in execute' .../rubygems/commands/outdated_command.rb:21:in `each' .../rubygems/commands/outdated_command.rb:21:in `execute' .../rubygems/command.rb:270:in `invoke' .../rubygems/command_manager.rb:134:in `process_args' .../rubygems/command_manager.rb:104:in `run' .../rubygems/gem_runner.rb:58:in `run' /opt/local/bin/gem1.9:21:in `
' That occurs on my machine because I have rails 3.0.0.beta3 and 2.3.5 installed, but 2.3.6 is out. I can fix this by updating Gem::Commands::OutdatedCommand to exclude prereleases when listing the outdated gems. Not sure if you'll want to somehow handle prereleases with gem outdated, tho. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28237&group_id=126 From noreply at rubyforge.org Sun May 23 14:03:24 2010 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 23 May 2010 14:03:24 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-28237 ] gem outdated fails for gems that are outdated but have a prerelease installed Message-ID: <20100523180324.7BFED185835E@rubyforge.org> Bugs item #28237, was opened at 2010-05-23 14:58 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28237&group_id=126 Category: `gem` commands (other) Group: v1.3.x Status: Open Resolution: None Priority: 3 Submitted By: Caio Chassot (cchassot) Assigned to: Nobody (None) Summary: gem outdated fails for gems that are outdated but have a prerelease installed Initial Comment: $ sudo gem1.9 outdated --backtrace ERROR: While executing gem ... (NoMethodError) undefined method `first' for nil:NilClass .../rubygems/commands/outdated_command.rb:26:in `block in execute' .../rubygems/commands/outdated_command.rb:21:in `each' .../rubygems/commands/outdated_command.rb:21:in `execute' .../rubygems/command.rb:270:in `invoke' .../rubygems/command_manager.rb:134:in `process_args' .../rubygems/command_manager.rb:104:in `run' .../rubygems/gem_runner.rb:58:in `run' /opt/local/bin/gem1.9:21:in `
' That occurs on my machine because I have rails 3.0.0.beta3 and 2.3.5 installed, but 2.3.6 is out. I can fix this by updating Gem::Commands::OutdatedCommand to exclude prereleases when listing the outdated gems. Not sure if you'll want to somehow handle prereleases with gem outdated, tho. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28237&group_id=126 From noreply at rubyforge.org Sun May 23 14:06:08 2010 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 23 May 2010 14:06:08 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-28237 ] gem outdated fails for gems that are outdated but have a prerelease installed Message-ID: <20100523180608.28A41167829F@rubyforge.org> Bugs item #28237, was opened at 2010-05-23 14:58 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28237&group_id=126 Category: `gem` commands (other) Group: v1.3.x Status: Open Resolution: None Priority: 3 Submitted By: Caio Chassot (cchassot) Assigned to: Nobody (None) Summary: gem outdated fails for gems that are outdated but have a prerelease installed Initial Comment: $ sudo gem1.9 outdated --backtrace ERROR: While executing gem ... (NoMethodError) undefined method `first' for nil:NilClass .../rubygems/commands/outdated_command.rb:26:in `block in execute' .../rubygems/commands/outdated_command.rb:21:in `each' .../rubygems/commands/outdated_command.rb:21:in `execute' .../rubygems/command.rb:270:in `invoke' .../rubygems/command_manager.rb:134:in `process_args' .../rubygems/command_manager.rb:104:in `run' .../rubygems/gem_runner.rb:58:in `run' /opt/local/bin/gem1.9:21:in `
' That occurs on my machine because I have rails 3.0.0.beta3 and 2.3.5 installed, but 2.3.6 is out. I can fix this by updating Gem::Commands::OutdatedCommand to exclude prereleases when listing the outdated gems. Not sure if you'll want to somehow handle prereleases with gem outdated, tho. ---------------------------------------------------------------------- >Comment By: Caio Chassot (cchassot) Date: 2010-05-23 15:06 Message: I made a simple patch that fixes the bug but doesn't otherwise enhance outdated to handle prereleases. Eg. if a prerelease itself is outdated, I'm not sure how that would be handled. I think prereleases are ignored by Gem::SourceIndex.outdated. (Our bug happens after that, during the printing of the outdated gems.) ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28237&group_id=126 From noreply at rubyforge.org Sun May 23 14:23:09 2010 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 23 May 2010 14:23:09 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-28238 ] gem update fails when released gem is outdated but a prerelease is installed Message-ID: <20100523182309.967BF167829F@rubyforge.org> Bugs item #28238, was opened at 2010-05-23 15:23 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28238&group_id=126 Category: `gem` commands (other) Group: v1.3.x Status: Open Resolution: None Priority: 3 Submitted By: Caio Chassot (cchassot) Assigned to: Nobody (None) Summary: gem update fails when released gem is outdated but a prerelease is installed Initial Comment: somewhat related to #28237 Eg. rails 2.3.5 won't update to 2.3.6 is 3.0.0.beta3 is installed. I think I fixed this by handling option[:prerelease] in update_command, but now when I run `gem update --pre` it insists in installing sinatra 1.0.b every time. FWIW: $ gem1.9 list sinatra *** LOCAL GEMS *** sinatra (1.0, 1.0.b, 1.0.a, 0.9.4, 0.9.2) ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28238&group_id=126 From noreply at rubyforge.org Sun May 23 14:29:47 2010 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 23 May 2010 14:29:47 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-28238 ] gem update fails when released gem is outdated but a prerelease is installed Message-ID: <20100523182947.53679185835D@rubyforge.org> Bugs item #28238, was opened at 2010-05-23 15:23 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28238&group_id=126 Category: `gem` commands (other) Group: v1.3.x Status: Open Resolution: None Priority: 3 Submitted By: Caio Chassot (cchassot) Assigned to: Nobody (None) Summary: gem update fails when released gem is outdated but a prerelease is installed Initial Comment: somewhat related to #28237 Eg. rails 2.3.5 won't update to 2.3.6 is 3.0.0.beta3 is installed. I think I fixed this by handling option[:prerelease] in update_command, but now when I run `gem update --pre` it insists in installing sinatra 1.0.b every time. FWIW: $ gem1.9 list sinatra *** LOCAL GEMS *** sinatra (1.0, 1.0.b, 1.0.a, 0.9.4, 0.9.2) ---------------------------------------------------------------------- >Comment By: Caio Chassot (cchassot) Date: 2010-05-23 15:29 Message: Obviously I meant: Eg. rails 2.3.5 won't update to 2.3.6 BECAUSE 3.0.0.beta3 is installed. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28238&group_id=126 From noreply at rubyforge.org Mon May 24 02:25:38 2010 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 24 May 2010 02:25:38 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-27575 ] Gem reports: WARNING: RubyGems 1.2+ index not found for Message-ID: <20100524062538.6FD681858351@rubyforge.org> Bugs item #27575, was opened at 2009-12-16 10:29 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27575&group_id=126 Category: other Group: v1.3.x Status: Closed Resolution: Rejected Priority: 3 Submitted By: Yann Golanski (kierun) Assigned to: Nobody (None) Summary: Gem reports: WARNING: RubyGems 1.2+ index not found for Initial Comment: I cannot update, install or do anything with gems because of this message. Does anyone have any idea? $ uname -a Linux desk4 2.6.31-16-generic #52-Ubuntu SMP Thu Dec 3 22:07:16 UTC 2009 x86_64 GNU/Linux $ gem -v 1.3.5 $ gem env RubyGems Environment: - RUBYGEMS VERSION: 1.3.5 - RUBY VERSION: 1.8.7 (2009-06-12 patchlevel 174) [x86_64-linux] - INSTALLATION DIRECTORY: /var/lib/gems/1.8 - RUBY EXECUTABLE: /usr/bin/ruby1.8 - EXECUTABLE DIRECTORY: /var/lib/gems/1.8/bin - RUBYGEMS PLATFORMS: - ruby - x86_64-linux - GEM PATHS: - /var/lib/gems/1.8 - /home/yann/.gem/ruby/1.8 - GEM CONFIGURATION: - :update_sources => true - :verbose => true - :benchmark => false - :backtrace => false - :bulk_threshold => 1000 - :sources => ["http://gems.rubyforge.org/", "http://gems.github.com"] - REMOTE SOURCES: - http://gems.rubyforge.org/ - http://gems.github.com $ gem install rainbow WARNING: RubyGems 1.2+ index not found for: http://gems.rubyforge.org/ RubyGems will revert to legacy indexes degrading performance. Bulk updating Gem source index for: http://gems.rubyforge.org/ ERROR: While executing gem ... (NoMethodError) undefined method `gems' for # ---------------------------------------------------------------------- Comment By: Edgar Gonzalez (eagoweb) Date: 2010-05-24 06:25 Message: i am having the same problem here, in a windows xp, 7.... this what i have: RubyGems Environment: - RUBYGEMS VERSION: 1.3.5 - RUBY VERSION: 1.8.7 (2010-01-10 patchlevel 249) [i386-mingw32] - INSTALLATION DIRECTORY: C:/Ruby/lib/ruby/gems/1.8 - RUBY EXECUTABLE: C:/Ruby/bin/ruby.exe - EXECUTABLE DIRECTORY: C:/Ruby/bin - RUBYGEMS PLATFORMS: - ruby - x86-mingw32 - GEM PATHS: - C:/Ruby/lib/ruby/gems/1.8 - C:/Users/edgardo/.gem/ruby/1.8 - GEM CONFIGURATION: - :update_sources => true - :verbose => true - :benchmark => false - :backtrace => false - :bulk_threshold => 1000 - :sources => ["http://gems.rubyforge.org/"] - REMOTE SOURCES: - http://gems.rubyforge.org/ i have changed sources, disabled firewalls.... but no results ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2009-12-17 03:29 Message: tee hee ---------------------------------------------------------------------- Comment By: Yann Golanski (kierun) Date: 2009-12-16 11:20 Message: Yes, it was a wonderful error between keyboard and floor. Someone (not me!) added an entry to /etc/hosts for gems.rubyforge.org which pointed to a daft IP. Close and ignore this bug. Sorry for wasting your time. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2009-12-16 11:12 Message: I've got rubygems 1.3.5 running on 1.8.7 as well. I've got gems.rubyforge.org as my only source and I can install rainbow just fine. So either I'm guessing that you hit the server while their index was missing or being generated or something else is causing the problem. You may want to try removing the github source, but I tested against that and it seems to also work fine. If you still have the problem, please add --debug and --backtrace and give us the full output. Thanks. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27575&group_id=126 From noreply at rubyforge.org Mon May 24 07:30:02 2010 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 24 May 2010 07:30:02 -0400 (EDT) Subject: [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 Message-ID: <20100524113002.366AF185836A@rubyforge.org> 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: Open Resolution: None Priority: 3 Submitted By: Randall Lucas (rlucas) Assigned to: Nobody (None) 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 * 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: 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 From noreply at rubyforge.org Mon May 24 13:16:53 2010 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 24 May 2010 13:16:53 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-27575 ] Gem reports: WARNING: RubyGems 1.2+ index not found for Message-ID: <20100524171653.9FDCB1678217@rubyforge.org> Bugs item #27575, was opened at 2009-12-16 10:29 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27575&group_id=126 Category: other Group: v1.3.x Status: Closed Resolution: Rejected Priority: 3 Submitted By: Yann Golanski (kierun) Assigned to: Nobody (None) Summary: Gem reports: WARNING: RubyGems 1.2+ index not found for Initial Comment: I cannot update, install or do anything with gems because of this message. Does anyone have any idea? $ uname -a Linux desk4 2.6.31-16-generic #52-Ubuntu SMP Thu Dec 3 22:07:16 UTC 2009 x86_64 GNU/Linux $ gem -v 1.3.5 $ gem env RubyGems Environment: - RUBYGEMS VERSION: 1.3.5 - RUBY VERSION: 1.8.7 (2009-06-12 patchlevel 174) [x86_64-linux] - INSTALLATION DIRECTORY: /var/lib/gems/1.8 - RUBY EXECUTABLE: /usr/bin/ruby1.8 - EXECUTABLE DIRECTORY: /var/lib/gems/1.8/bin - RUBYGEMS PLATFORMS: - ruby - x86_64-linux - GEM PATHS: - /var/lib/gems/1.8 - /home/yann/.gem/ruby/1.8 - GEM CONFIGURATION: - :update_sources => true - :verbose => true - :benchmark => false - :backtrace => false - :bulk_threshold => 1000 - :sources => ["http://gems.rubyforge.org/", "http://gems.github.com"] - REMOTE SOURCES: - http://gems.rubyforge.org/ - http://gems.github.com $ gem install rainbow WARNING: RubyGems 1.2+ index not found for: http://gems.rubyforge.org/ RubyGems will revert to legacy indexes degrading performance. Bulk updating Gem source index for: http://gems.rubyforge.org/ ERROR: While executing gem ... (NoMethodError) undefined method `gems' for # ---------------------------------------------------------------------- Comment By: Edgar Gonzalez (eagoweb) Date: 2010-05-24 17:16 Message: OK now i see, the problem are with the dns configuration, with my local dns configuration in Dominican Republic i cannot access RubyForge :s.... so i changed to google public dns and now everything works great :) ---------------------------------------------------------------------- Comment By: Edgar Gonzalez (eagoweb) Date: 2010-05-24 06:25 Message: i am having the same problem here, in a windows xp, 7.... this what i have: RubyGems Environment: - RUBYGEMS VERSION: 1.3.5 - RUBY VERSION: 1.8.7 (2010-01-10 patchlevel 249) [i386-mingw32] - INSTALLATION DIRECTORY: C:/Ruby/lib/ruby/gems/1.8 - RUBY EXECUTABLE: C:/Ruby/bin/ruby.exe - EXECUTABLE DIRECTORY: C:/Ruby/bin - RUBYGEMS PLATFORMS: - ruby - x86-mingw32 - GEM PATHS: - C:/Ruby/lib/ruby/gems/1.8 - C:/Users/edgardo/.gem/ruby/1.8 - GEM CONFIGURATION: - :update_sources => true - :verbose => true - :benchmark => false - :backtrace => false - :bulk_threshold => 1000 - :sources => ["http://gems.rubyforge.org/"] - REMOTE SOURCES: - http://gems.rubyforge.org/ i have changed sources, disabled firewalls.... but no results ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2009-12-17 03:29 Message: tee hee ---------------------------------------------------------------------- Comment By: Yann Golanski (kierun) Date: 2009-12-16 11:20 Message: Yes, it was a wonderful error between keyboard and floor. Someone (not me!) added an entry to /etc/hosts for gems.rubyforge.org which pointed to a daft IP. Close and ignore this bug. Sorry for wasting your time. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2009-12-16 11:12 Message: I've got rubygems 1.3.5 running on 1.8.7 as well. I've got gems.rubyforge.org as my only source and I can install rainbow just fine. So either I'm guessing that you hit the server while their index was missing or being generated or something else is causing the problem. You may want to try removing the github source, but I tested against that and it seems to also work fine. If you still have the problem, please add --debug and --backtrace and give us the full output. Thanks. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27575&group_id=126 From noreply at rubyforge.org Tue May 25 18:06:39 2010 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 25 May 2010 18:06:39 -0400 (EDT) Subject: [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 Message-ID: <20100525220639.11CB41D799D4@rubyforge.org> 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: None Priority: 3 Submitted By: Randall Lucas (rlucas) Assigned to: Nobody (None) 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 * 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: 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 From noreply at rubyforge.org Tue May 25 18:27:01 2010 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 25 May 2010 18:27:01 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-28238 ] gem update fails when released gem is outdated but a prerelease is installed Message-ID: <20100525222701.1155E1D799D4@rubyforge.org> Bugs item #28238, was opened at 2010-05-23 11:23 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28238&group_id=126 Category: `gem` commands (other) Group: v1.3.x Status: Open Resolution: None Priority: 3 Submitted By: Caio Chassot (cchassot) Assigned to: Nobody (None) Summary: gem update fails when released gem is outdated but a prerelease is installed Initial Comment: somewhat related to #28237 Eg. rails 2.3.5 won't update to 2.3.6 is 3.0.0.beta3 is installed. I think I fixed this by handling option[:prerelease] in update_command, but now when I run `gem update --pre` it insists in installing sinatra 1.0.b every time. FWIW: $ gem1.9 list sinatra *** LOCAL GEMS *** sinatra (1.0, 1.0.b, 1.0.a, 0.9.4, 0.9.2) ---------------------------------------------------------------------- >Comment By: Eric Hodel (drbrain) Date: 2010-05-25 15:27 Message: 2.3.6 is a lesser version than 3.0.0.beta3. If you want to install a lesser version than one you already have installed use `gem install rails --version 2.3.6`. If you elect to use prereleases you can expect to have to do more work in managing your gems. `gem update --prerelease` means "allow updating to prerelease versions", so the behavior you're seeing is correct (but that appears to be a separate issue, please file a separate ticket for it). ---------------------------------------------------------------------- Comment By: Caio Chassot (cchassot) Date: 2010-05-23 11:29 Message: Obviously I meant: Eg. rails 2.3.5 won't update to 2.3.6 BECAUSE 3.0.0.beta3 is installed. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28238&group_id=126 From noreply at rubyforge.org Wed May 26 01:13:54 2010 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 26 May 2010 01:13:54 -0400 (EDT) Subject: [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 Message-ID: <20100526051354.2B9411858351@rubyforge.org> 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: None Priority: 3 Submitted By: Randall Lucas (rlucas) Assigned to: Nobody (None) 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 * 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: 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 From jftucker at gmail.com Wed May 26 08:35:01 2010 From: jftucker at gmail.com (James Tucker) Date: Wed, 26 May 2010 09:35:01 -0300 Subject: [Rubygems-developers] API access to versions in list command In-Reply-To: References: Message-ID: On 23 May 2010, at 07:40, Chad Woolley wrote: > On Sun, May 23, 2010 at 1:21 AM, Chad Woolley wrote: >> 1. Are we doing it wrong? Does the RubyGems API provide a way to avoid >> this manual parsing? >> 2. Should there be a --[no-]platforms option to the 'list' command, >> which would have made these updates to the parsing logic unnecessary? > > So, I found Eric Hodel's admonishment "Why aren't you using the > RubyGems API?" [1], but that's easier said than done. James Tucker > followed with this example [2], but that doesn't help, because it > isn't a remote call (just gives an array of "name-version" local > entries). > > The only thing the API provides now is Gem.source_index for local > gems, and Gem::SpecFetcher.fetcher for remote gems. Both of these > return giant nested hashes and arrays of various nested values and > objects. That's not too user-friendly or intuitive, which is why I > think people just end up parsing the output of gem list. Oooh, you're using --remote. Ok, now I understand the problem! sorry about that. > For example, here's the API call to see if a gem with the specified > name_to_find, version_to_find, and platform_to_find exists remotely: > > name_to_find=/^json$/; version_to_find = '1.4.3'; > platform_to_find='x86-mingw32'; > Gem::SpecFetcher.fetcher.find_matching(Gem::Dependency.new(name_to_find,version_to_find),false,false).map{|spec_tuple| > spec = spec_tuple.first; spec[2] == platform_to_find }.any?{|found| > found == true} > > Is there something simpler? Maybe. I'm not sure. Like I said, not > very intuitive, and looking at the RubyGems code for examples doesn't > help much (e.g. the 225-line query_command#output_query_results) Gem::SpecFetcher.fetcher.list.values.flatten(1).map { |n, v, p| [n,v.to_s] }.uniq[0..3] # => [["_", "1.2"], ["-", "1"], ["2Performant", "0.0.2"], ["360_services", "1.1.3"]] > What are the problems? > > One problem is the lack of objects here. Returning a giant nested > hash or array isn't a humane API. What kind of objects do you want that are more humane? Simple data structures can be coerced easily, and everyone knows how to wrangle them. > A second problem is the coupling of the version and platform concepts. > Ideally, I'd like to have these abstractions: > > * A Gem has one or more Versions. > * Each Version has one or more Platforms. Gem::SpecFetcher.fetcher.list.values.flatten(1).group_by { |n,v,p| n } > Instead, SpecFetcher provides this representation of the platforms > supported by a specific gem name and version: > > Gem::SpecFetcher.fetcher.find_matching(Gem::Dependency.new(/^json$/,'1.4.3'),true,false) > > [[["json", #, "x86-mingw32"], > "http://rubygems.org/"], [["json", #, "ruby"], > "http://rubygems.org/"], [["json", #, > "x86-mswin32"], "http://rubygems.org/"]] > > What can we do? What exactly are you trying to do, and what for? I know 'chef', but what specific tasks? > When I think of an "easy" API for this, it's kind of hard given these > issues. Maybe we could at least provide something for the common use > case chef and geminstaller had, which is "does this gem name (and > optionally version/platform) exist remotely?" Yes, the platform portion is an issue. The API was originally built to satisfy local platform settings, obviously overridable by the --platform option, but that is currently singleton, and not a good choice for you guys, I agree. It's still not /that/ bad, all things considered: Gem::SpecFetcher.fetcher.list(true, true).values.flatten(1).find { |n,v,p| n == name && v == version && p == platform } > exists_remotely?(name, version=nil, platform=nil) > > where version and and platform would be defaulted to match anything. > This method could be anywhere, on Gem, or a FriendlyApi module mixed > into Gem; whatever as it is intuitive and easily found. Or on Gem::SpecFetcher? > Anyway, just some thoughts, because it's not cool to tell people "Use > the API!" when that is only possible given a fairly deep understanding > of RubyGems internals... Written using irb(1) in about 5 minutes. From noreply at rubyforge.org Wed May 26 13:15:11 2010 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 26 May 2010 13:15:11 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-28238 ] gem update fails when released gem is outdated but a prerelease is installed Message-ID: <20100526171511.EBE7B1858344@rubyforge.org> Bugs item #28238, was opened at 2010-05-23 15:23 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28238&group_id=126 Category: `gem` commands (other) Group: v1.3.x Status: Open Resolution: None Priority: 3 Submitted By: Caio Chassot (cchassot) >Assigned to: Eric Hodel (drbrain) Summary: gem update fails when released gem is outdated but a prerelease is installed Initial Comment: somewhat related to #28237 Eg. rails 2.3.5 won't update to 2.3.6 is 3.0.0.beta3 is installed. I think I fixed this by handling option[:prerelease] in update_command, but now when I run `gem update --pre` it insists in installing sinatra 1.0.b every time. FWIW: $ gem1.9 list sinatra *** LOCAL GEMS *** sinatra (1.0, 1.0.b, 1.0.a, 0.9.4, 0.9.2) ---------------------------------------------------------------------- >Comment By: Caio Chassot (cchassot) Date: 2010-05-26 14:15 Message: I hear what you're saying, but is there any downside to being smart about updating released gems regardless of having a larger version installed as pre- release? > (but that appears to be a separate issue, please file a separate ticket for it). I'll gladly open said ticket, but what issue exactly are you talking about here? ---------------------------------------------------------------------- Comment By: Eric Hodel (drbrain) Date: 2010-05-25 19:27 Message: 2.3.6 is a lesser version than 3.0.0.beta3. If you want to install a lesser version than one you already have installed use `gem install rails --version 2.3.6`. If you elect to use prereleases you can expect to have to do more work in managing your gems. `gem update --prerelease` means "allow updating to prerelease versions", so the behavior you're seeing is correct (but that appears to be a separate issue, please file a separate ticket for it). ---------------------------------------------------------------------- Comment By: Caio Chassot (cchassot) Date: 2010-05-23 15:29 Message: Obviously I meant: Eg. rails 2.3.5 won't update to 2.3.6 BECAUSE 3.0.0.beta3 is installed. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28238&group_id=126 From ryand-ruby at zenspider.com Wed May 26 23:06:36 2010 From: ryand-ruby at zenspider.com (Ryan Davis) Date: Wed, 26 May 2010 20:06:36 -0700 Subject: [Rubygems-developers] [ rubygems-Bugs-28238 ] gem update fails when released gem is outdated but a prerelease is installed In-Reply-To: <20100525222701.1155E1D799D4@rubyforge.org> References: <20100525222701.1155E1D799D4@rubyforge.org> Message-ID: <138CA916-C09A-4375-82E9-72B26AD1869D@zenspider.com> On May 25, 2010, at 15:27 , wrote: > `gem update --prerelease` means "allow updating to prerelease versions", so the behavior you're seeing is correct (but that appears to be a separate issue, please file a separate ticket for it). Is this a 'no'able option? gem update --noprerelease