From noreply at rubyforge.org Wed Dec 1 05:54:24 2010 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 1 Dec 2010 05:54:24 -0500 (EST) Subject: [Rubygems-developers] [ rubygems-Bugs-27154 ] Computed hash is sometimes too large. Message-ID: <20101201105425.C881F1858378@rubyforge.org> Bugs item #27154, was opened at 2009-09-21 07:42 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27154&group_id=126 Category: `gem install` command Group: None >Status: Open Resolution: None Priority: 3 Submitted By: Ryan Riley (panesofglass) >Assigned to: John Barnette (jbarnette) Summary: Computed hash is sometimes too large. Initial Comment: The current hash algorithm in dependency.rb (line 138) and specification.rb (line 658) can sometimes create a hash that is too large. This is also possible with Array#hash in MRI, which can also misbehave if one of the array elements returns a large hash value: class C def hash 100000000000000000000 end end [C.new].hash # => in `hash': bignum too big to convert into `long' (RangeError) REXML has a similar issue. http://redmine.ruby- lang.org/issues/show/1883 tracks the issue, and MRI will be fixing the issue. Suggested fixes are: edit: c:/ruby/libs/ruby/site_ruby/1.8/rubygems/dependency.rb;C840659 File: dependency.rb =================================================================== --- c:/ruby/libs/ruby/site_ruby/1.8/rubygems/dependency.rb;C840659 (server) 6/23/2009 1:21 PM +++ c:/ruby/libs/ruby/site_ruby/1.8/rubygems/dependency.rb @@ -112,7 +112,7 @@ end def hash # :nodoc: - name.hash + type.hash + version_requirements.hash + name.hash ^ type.hash ^ version_requirements.hash end end =================================================================== edit: c:/ruby/libs/ruby/site_ruby/1.8/rubygems/specification.rb;C908357 File: specification.rb =================================================================== --- c:/ruby/libs/ruby/site_ruby/1.8/rubygems/specification.rb;C908357 (server) 6/23/2009 1:24 PM +++ c:/ruby/libs/ruby/site_ruby/1.8/rubygems/specification.rb @@ -661,9 +661,8 @@ private :same_attributes? def hash # :nodoc: - @@attributes.inject(0) { |hash_code, (name, default_value)| - n = self.send(name).hash - hash_code + n + @@attributes.inject(612553) { |hash_code, (name, default_value)| + hash_code ^ self.send(name).hash } end =================================================================== ---------------------------------------------------------------------- Comment By: George Mendoza (gsmendoza) Date: 2010-11-30 19:52 Message: Hello, Appreciate if anybody can re-open this ticket. I am also getting the error when I try to install the dmitryv-backup gem via bundle. Please let me know if I need to provide any other information in order to fix this bug. Thanks! Gemfile: ---------------------------------------- source :rubygems source "http://gems.github.com" #... gem 'dmitryv-backup', '2.4.0', :require => "backup" #... ---------------------------------------- Running: ---------------------------------------- bundle install --local /usr/local/lib/site_ruby/1.8/rubygems/requirement.rb:109:in `hash': bignum too big to convert into `long' (RangeError) from /usr/local/lib/site_ruby/1.8/rubygems/requirement.rb:109:in `hash' from /usr/local/lib/site_ruby/1.8/rubygems/specification.rb:675:in `hash' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/index.rb:36:in `inject' from /usr/local/lib/site_ruby/1.8/rubygems/specification.rb:674:in `each' from /usr/local/lib/site_ruby/1.8/rubygems/specification.rb:674:in `inject' from /usr/local/lib/site_ruby/1.8/rubygems/specification.rb:674:in `hash' from /usr/lib/ruby/1.8/tsort.rb:204:in `include?' from /usr/lib/ruby/1.8/tsort.rb:204:in `each_strongly_connected_component_from' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/spec_set.rb:130:in `tsort_each_child' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/spec_set.rb:130:in `each' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/spec_set.rb:130:in `tsort_each_child' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/spec_set.rb:128:in `each' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/spec_set.rb:128:in `tsort_each_child' from /usr/lib/ruby/1.8/tsort.rb:203:in `each_strongly_connected_component_from' from /usr/lib/ruby/1.8/tsort.rb:209:in `each_strongly_connected_component_from' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/spec_set.rb:130:in `tsort_each_child' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/spec_set.rb:130:in `each' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/spec_set.rb:130:in `tsort_each_child' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/spec_set.rb:128:in `each' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/spec_set.rb:128:in `tsort_each_child' from /usr/lib/ruby/1.8/tsort.rb:203:in `each_strongly_connected_component_from' from /usr/lib/ruby/1.8/tsort.rb:182:in `each_strongly_connected_component' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/spec_set.rb:124:in `tsort_each_node' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/spec_set.rb:124:in `each' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/spec_set.rb:124:in `tsort_each_node' from /usr/lib/ruby/1.8/tsort.rb:180:in `each_strongly_connected_component' from /usr/lib/ruby/1.8/tsort.rb:148:in `tsort_each' from /usr/lib/ruby/1.8/tsort.rb:135:in `tsort' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/spec_set.rb:107:in `sorted' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/spec_set.rb:12:in `each' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/installer.rb:44:in `run' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/installer.rb:8:in `install' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/cli.rb:225:in `install' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/vendor/thor/task.rb:22:in `send' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/vendor/thor/task.rb:22:in `run' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/vendor/thor/invocation.rb:118:in `invoke_task' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/vendor/thor.rb:246:in `dispatch' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/vendor/thor/base.rb:389:in `start' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/bin/bundle:13 from /usr/bin/bundle:19:in `load' from /usr/bin/bundle:19 ---------------------------------------- Thanks, George Mendoza Philippines ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2010-11-12 14:46 Message: This ticket has been deemed stale and we're closing it in order to catch up with our ticket list. If you think it is still valid, please reopen. ---------------------------------------------------------------------- Comment By: Craig Cook (ccook) Date: 2010-10-18 14:08 Message: Hello, I tried this patch, but I am still getting the error, at the same place in the code. The error is the same with or without the patch to specification.rb; dependency.rb was already like the patched part shown above. This happened when installing using bundler, executed via capistrano. We had been using hpricot, it wasn't needed, it was giving this error first. I took it out, but then the same RangeError happened with mysql. I've seen it before also with nokogiri. (Always with native gems, though). Here's the relevant part of the log: ----------- begin log ---------------------------- ** [out :: 192.168.10.63] Installing mysql (2.8.1) ** [out :: 192.168.10.63] with native extensions ** [out :: 192.168.10.62] /usr/lib/ruby/site_ruby/1.8/rubygems/requirement.rb:109:in `hash' ** [out :: 192.168.10.62] : ** [out :: 192.168.10.62] bignum too big to convert into `long' ** [out :: 192.168.10.62] ( ** [out :: 192.168.10.62] RangeError ** [out :: 192.168.10.62] ) ** [out :: 192.168.10.62] from /usr/lib/ruby/site_ruby/1.8/rubygems/requirement.rb:109:in `hash' ** [out :: 192.168.10.62] from /usr/lib/ruby/site_ruby/1.8/rubygems/specification.rb:675:in `hash' ** [out :: 192.168.10.62] from /usr/lib/ruby/1.8/fileutils.rb:243:in `inject' ** [out :: 192.168.10.62] from /usr/lib/ruby/site_ruby/1.8/rubygems/specification.rb:674:in `each' ** [out :: 192.168.10.62] from /usr/lib/ruby/site_ruby/1.8/rubygems/specification.rb:674:in `inject' ** [out :: 192.168.10.62] from /usr/lib/ruby/site_ruby/1.8/rubygems/specification.rb:674:in `hash' ** [out :: 192.168.10.62] from /usr/lib/ruby/1.8/tsort.rb:205:in `include?' ** [out :: 192.168.10.62] from /usr/lib/ruby/1.8/tsort.rb:205:in `each_strongly_connected_component_from' ** [out :: 192.168.10.62] ... 22 levels... ** [out :: 192.168.10.62] from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.2/lib/bundler/vendor/thor/base.rb:389:in `start' ** [out :: 192.168.10.62] from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.2/bin/bundle:13 ** [out :: 192.168.10.62] from /usr/bin/bundle:19:in `load' ** [out :: 192.168.10.62] from /usr/bin/bundle:19 ----------- end cap output ------------------- running: ------------ system & ruby info ------------------ [ccook at ev2-stage ~]$ ruby -v ruby 1.8.7 (2010-08-16 patchlevel 302) [i686-linux] [ccook at ev2-stage ~]$ gem -v 1.3.7 [ccook at ev2-stage ~]$ uname -a Linux ev2-stage 2.6.18-194.11.4.el5xen #1 SMP Tue Sep 21 06:28:04 EDT 2010 i686 i686 i386 GNU/Linux ------ end system / ruby info ---------- Gemfile: ----------- begin Gemfile ----------------- source :gemcutter gem 'rails', '2.3.8' gem 'mysql', '2.8.1' gem "geokit" gem "geokit-rails" gem "builder" gem 'chronic' gem 'whenever' gem 'database_cleaner' gem 'apn_on_rails' gem 'factory_girl' gem 'net-sftp' gem 'will_paginate' # dependency for squirrel & jqgrid gem 'nokogiri' # only for test/functional/auth_controller_test.rb gem 'cucumber' gem 'cucumber-rails' gem 'webrat' gem 'rspec' ---------- end Gemfile ----------------- So, is this the same issue? It sure looks like it to me. I hope not to have to dive into the innards of rubygems if possible. But we need to be able to deploy. The app is working and passing tests on development, but hard to say on staging as we can't get it over there with cap. I suppose it could all be done by hand once anyway, but we (other dev on my team and I ) need to be able to do this over again. Thanks for your time in this! Cheers, Craig ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27154&group_id=126 From transfire at gmail.com Wed Dec 1 07:20:09 2010 From: transfire at gmail.com (Trans) Date: Wed, 1 Dec 2010 04:20:09 -0800 (PST) Subject: [Rubygems-developers] Remove RDoc generation In-Reply-To: <2A905ED8-53BB-4BFB-8B47-BBDCDB3BCA2A@gmail.com> References: <9A715088-1DC2-4BD8-B013-C71C2966861C@zenspider.com> <95590ec2-6bfd-4253-9c26-fe187416dd9c@z9g2000yqz.googlegroups.com> <2A905ED8-53BB-4BFB-8B47-BBDCDB3BCA2A@gmail.com> Message-ID: <6c6a9f3b-5b1f-4879-80d6-de800c6d44c3@f21g2000prn.googlegroups.com> On Nov 30, 1:21?pm, James Tucker wrote: > On 30 Nov 2010, at 02:17, Trans wrote: > > > > > On Nov 29, 6:38 pm, Ryan Davis wrote: > >> On Nov 29, 2010, at 11:42 , Trans wrote: > > >>> With YARD becoming so popular > > >> You can just stop right there. > > >> yard only has 50k downloads, 2.5k for the last version. > > >> rdoc has 250k downloads, 73k for the last version. > > > I would think 2,500 users is fairly significant. But that's not the > > main point. On demand generation of docs is a better idea. > > Patch please. I went ahead with it this morning. The main of the patch is done. But I ran into one issue. When the web app generates the rdocs it gets a write permission error unless the server is running sudo. Not sure there is any way to get around this. Any ideas? Beyond that, either run sudo or under rvm and it won't be an issue. > _______________________________________________ > Rubygems-developers mailing listhttp://rubyforge.org/projects/rubygems > Rubygems-develop... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/rubygems-developers From noreply at rubyforge.org Wed Dec 1 12:33:51 2010 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 1 Dec 2010 12:33:51 -0500 (EST) Subject: [Rubygems-developers] [ rubygems-Bugs-28759 ] Print message when no gems matching your platform are found, or could not be installed Message-ID: <20101201173352.0D5C51858378@rubyforge.org> Bugs item #28759, was opened at 2010-11-30 11:22 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28759&group_id=126 Category: `gem install` command Group: None Status: Open Resolution: None Priority: 3 Submitted By: Greg Hazel (ghazel) Assigned to: Nobody (None) Summary: Print message when no gems matching your platform are found, or could not be installed Initial Comment: reopening: http://rubyforge.org/tracker/?func=detail&atid=575&aid=21325&group_id=126 Example of the problem today: $ uname -a Linux hostname 2.6.21.7-2.fc8xen #1 SMP Fri Feb 15 12:34:28 EST 2008 x86_64 x86_64 x86_64 GNU/Linux $ sudo gem search -r nokogiri *** REMOTE GEMS *** glebm-nokogiri (1.4.2.1) jwagener-nokogiri (1.4.1) nokogiri (1.4.4.1, 1.4.4, 1.2.3) nokogiri-diff (0.1.0) nokogiri-happymapper (0.3.4) nokogiri-plist (0.3.1) nokogiri-pretty (0.1.0) revo-nokogiri (1.4.1) rsolr-nokogiri (0.0.0) rubyjedi-nokogiri_java (1.4.0.20100513161003) superfeedr-nokogiri (1.4.0.20091116183308) $ sudo gem install nokogiri --version ">= 1.4.4.1" ERROR: could not find gem nokogiri locally or in a repository ---------------------------------------------------------------------- >Comment By: Eric Hodel (drbrain) Date: 2010-12-01 09:33 Message: Why would you try to install nokogiri for windows on purpose when it is clearly listed as such in `gem search`? $ gem search -r nokogiri *** REMOTE GEMS *** glebm-nokogiri (1.4.2.1) jwagener-nokogiri (1.4.1) nokogiri (1.4.4.1 x86-mingw32 x86-mswin32, 1.4.4 ruby java, 1.2.3 x86-mswin32-60) nokogiri-diff (0.1.0) nokogiri-happymapper (0.3.4) nokogiri-plist (0.3.1) nokogiri-pretty (0.1.0) revo-nokogiri (1.4.1 java) rsolr-nokogiri (0.0.0) rubyjedi-nokogiri_java (1.4.0.20100513161003 java) superfeedr-nokogiri (1.4.0.20091116183308) ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28759&group_id=126 From noreply at rubyforge.org Wed Dec 1 12:34:12 2010 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 1 Dec 2010 12:34:12 -0500 (EST) Subject: [Rubygems-developers] [ rubygems-Bugs-28759 ] Print message when no gems matching your platform are found, or could not be installed Message-ID: <20101201173412.D44E61858356@rubyforge.org> Bugs item #28759, was opened at 2010-11-30 11:22 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28759&group_id=126 Category: `gem install` command Group: None Status: Open Resolution: None Priority: 3 Submitted By: Greg Hazel (ghazel) Assigned to: Nobody (None) Summary: Print message when no gems matching your platform are found, or could not be installed Initial Comment: reopening: http://rubyforge.org/tracker/?func=detail&atid=575&aid=21325&group_id=126 Example of the problem today: $ uname -a Linux hostname 2.6.21.7-2.fc8xen #1 SMP Fri Feb 15 12:34:28 EST 2008 x86_64 x86_64 x86_64 GNU/Linux $ sudo gem search -r nokogiri *** REMOTE GEMS *** glebm-nokogiri (1.4.2.1) jwagener-nokogiri (1.4.1) nokogiri (1.4.4.1, 1.4.4, 1.2.3) nokogiri-diff (0.1.0) nokogiri-happymapper (0.3.4) nokogiri-plist (0.3.1) nokogiri-pretty (0.1.0) revo-nokogiri (1.4.1) rsolr-nokogiri (0.0.0) rubyjedi-nokogiri_java (1.4.0.20100513161003) superfeedr-nokogiri (1.4.0.20091116183308) $ sudo gem install nokogiri --version ">= 1.4.4.1" ERROR: could not find gem nokogiri locally or in a repository ---------------------------------------------------------------------- >Comment By: Eric Hodel (drbrain) Date: 2010-12-01 09:34 Message: Note: $ gem env version 1.3.7 ---------------------------------------------------------------------- Comment By: Eric Hodel (drbrain) Date: 2010-12-01 09:33 Message: Why would you try to install nokogiri for windows on purpose when it is clearly listed as such in `gem search`? $ gem search -r nokogiri *** REMOTE GEMS *** glebm-nokogiri (1.4.2.1) jwagener-nokogiri (1.4.1) nokogiri (1.4.4.1 x86-mingw32 x86-mswin32, 1.4.4 ruby java, 1.2.3 x86-mswin32-60) nokogiri-diff (0.1.0) nokogiri-happymapper (0.3.4) nokogiri-plist (0.3.1) nokogiri-pretty (0.1.0) revo-nokogiri (1.4.1 java) rsolr-nokogiri (0.0.0) rubyjedi-nokogiri_java (1.4.0.20100513161003 java) superfeedr-nokogiri (1.4.0.20091116183308) ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28759&group_id=126 From noreply at rubyforge.org Wed Dec 1 12:37:43 2010 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 1 Dec 2010 12:37:43 -0500 (EST) Subject: [Rubygems-developers] [ rubygems-Bugs-28759 ] Print message when no gems matching your platform are found, or could not be installed Message-ID: <20101201173744.0F676167831B@rubyforge.org> Bugs item #28759, was opened at 2010-11-30 11:22 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28759&group_id=126 Category: `gem install` command Group: None Status: Open Resolution: None Priority: 3 Submitted By: Greg Hazel (ghazel) Assigned to: Nobody (None) Summary: Print message when no gems matching your platform are found, or could not be installed Initial Comment: reopening: http://rubyforge.org/tracker/?func=detail&atid=575&aid=21325&group_id=126 Example of the problem today: $ uname -a Linux hostname 2.6.21.7-2.fc8xen #1 SMP Fri Feb 15 12:34:28 EST 2008 x86_64 x86_64 x86_64 GNU/Linux $ sudo gem search -r nokogiri *** REMOTE GEMS *** glebm-nokogiri (1.4.2.1) jwagener-nokogiri (1.4.1) nokogiri (1.4.4.1, 1.4.4, 1.2.3) nokogiri-diff (0.1.0) nokogiri-happymapper (0.3.4) nokogiri-plist (0.3.1) nokogiri-pretty (0.1.0) revo-nokogiri (1.4.1) rsolr-nokogiri (0.0.0) rubyjedi-nokogiri_java (1.4.0.20100513161003) superfeedr-nokogiri (1.4.0.20091116183308) $ sudo gem install nokogiri --version ">= 1.4.4.1" ERROR: could not find gem nokogiri locally or in a repository ---------------------------------------------------------------------- >Comment By: Greg Hazel (ghazel) Date: 2010-12-01 09:37 Message: I have gem 1.3.5 where that information is not listed. How hard is a more informative error message? ---------------------------------------------------------------------- Comment By: Eric Hodel (drbrain) Date: 2010-12-01 09:34 Message: Note: $ gem env version 1.3.7 ---------------------------------------------------------------------- Comment By: Eric Hodel (drbrain) Date: 2010-12-01 09:33 Message: Why would you try to install nokogiri for windows on purpose when it is clearly listed as such in `gem search`? $ gem search -r nokogiri *** REMOTE GEMS *** glebm-nokogiri (1.4.2.1) jwagener-nokogiri (1.4.1) nokogiri (1.4.4.1 x86-mingw32 x86-mswin32, 1.4.4 ruby java, 1.2.3 x86-mswin32-60) nokogiri-diff (0.1.0) nokogiri-happymapper (0.3.4) nokogiri-plist (0.3.1) nokogiri-pretty (0.1.0) revo-nokogiri (1.4.1 java) rsolr-nokogiri (0.0.0) rubyjedi-nokogiri_java (1.4.0.20100513161003 java) superfeedr-nokogiri (1.4.0.20091116183308) ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28759&group_id=126 From jftucker at gmail.com Wed Dec 1 13:41:51 2010 From: jftucker at gmail.com (James Tucker) Date: Wed, 1 Dec 2010 10:41:51 -0800 Subject: [Rubygems-developers] Remove RDoc generation In-Reply-To: <6c6a9f3b-5b1f-4879-80d6-de800c6d44c3@f21g2000prn.googlegroups.com> References: <9A715088-1DC2-4BD8-B013-C71C2966861C@zenspider.com> <95590ec2-6bfd-4253-9c26-fe187416dd9c@z9g2000yqz.googlegroups.com> <2A905ED8-53BB-4BFB-8B47-BBDCDB3BCA2A@gmail.com> <6c6a9f3b-5b1f-4879-80d6-de800c6d44c3@f21g2000prn.googlegroups.com> Message-ID: <94E9A201-F4DA-4573-9C6F-FC1980785EA6@gmail.com> On 1 Dec 2010, at 04:20, Trans wrote: > > > On Nov 30, 1:21 pm, James Tucker wrote: >> On 30 Nov 2010, at 02:17, Trans wrote: >> >> >> >>> On Nov 29, 6:38 pm, Ryan Davis wrote: >>>> On Nov 29, 2010, at 11:42 , Trans wrote: >> >>>>> With YARD becoming so popular >> >>>> You can just stop right there. >> >>>> yard only has 50k downloads, 2.5k for the last version. >> >>>> rdoc has 250k downloads, 73k for the last version. >> >>> I would think 2,500 users is fairly significant. But that's not the >>> main point. On demand generation of docs is a better idea. >> >> Patch please. > > I went ahead with it this morning. The main of the patch is done. But > I ran into one issue. When the web app generates the rdocs it gets a > write permission error unless the server is running sudo. Not sure > there is any way to get around this. Any ideas? Beyond that, either > run sudo or under rvm and it won't be an issue. Hmm, I think it may need some work to support the user install location too (see Gem.path). Once it supports the user path, maybe they could be generated in that location instead of the system location? Sounds like you're making sterling progress, thanks! From transfire at gmail.com Wed Dec 1 15:19:57 2010 From: transfire at gmail.com (Trans) Date: Wed, 1 Dec 2010 12:19:57 -0800 (PST) Subject: [Rubygems-developers] Remove RDoc generation In-Reply-To: <94E9A201-F4DA-4573-9C6F-FC1980785EA6@gmail.com> References: <9A715088-1DC2-4BD8-B013-C71C2966861C@zenspider.com> <95590ec2-6bfd-4253-9c26-fe187416dd9c@z9g2000yqz.googlegroups.com> <2A905ED8-53BB-4BFB-8B47-BBDCDB3BCA2A@gmail.com> <6c6a9f3b-5b1f-4879-80d6-de800c6d44c3@f21g2000prn.googlegroups.com> <94E9A201-F4DA-4573-9C6F-FC1980785EA6@gmail.com> Message-ID: <886be148-c01b-472b-8c9a-8efb8a034829@v17g2000prc.googlegroups.com> On Dec 1, 1:41?pm, James Tucker wrote: > Hmm, I think it may need some work to support the user install location too (see Gem.path). Once it supports the user path, maybe they could be generated in that location instead of the system location? If the gem is installed in the user location, then the documentation will be generated there too. I'm not sure about forcing all docs to be generated to the user location, but that's an idea. What do others think? The other option is to just present an error page saying why the rdocs could not be generated and what can be done about it. From thewoolleyman at gmail.com Wed Dec 1 16:25:40 2010 From: thewoolleyman at gmail.com (Chad Woolley) Date: Wed, 1 Dec 2010 14:25:40 -0700 Subject: [Rubygems-developers] Remove RDoc generation In-Reply-To: <886be148-c01b-472b-8c9a-8efb8a034829@v17g2000prc.googlegroups.com> References: <9A715088-1DC2-4BD8-B013-C71C2966861C@zenspider.com> <95590ec2-6bfd-4253-9c26-fe187416dd9c@z9g2000yqz.googlegroups.com> <2A905ED8-53BB-4BFB-8B47-BBDCDB3BCA2A@gmail.com> <6c6a9f3b-5b1f-4879-80d6-de800c6d44c3@f21g2000prn.googlegroups.com> <94E9A201-F4DA-4573-9C6F-FC1980785EA6@gmail.com> <886be148-c01b-472b-8c9a-8efb8a034829@v17g2000prc.googlegroups.com> Message-ID: On Wed, Dec 1, 2010 at 1:19 PM, Trans wrote: > The other option is to just present an error page saying why > the rdocs could not be generated and what can be done about it. If they need sudo access to install the rdoc, won't they also need it to install the gem files? And doesn't that just fail now with a write permission error? Why can't rdoc behave the same way, or is there something else to consider? -- Chad From transfire at gmail.com Thu Dec 2 10:49:31 2010 From: transfire at gmail.com (Trans) Date: Thu, 2 Dec 2010 07:49:31 -0800 (PST) Subject: [Rubygems-developers] Remove RDoc generation In-Reply-To: References: <9A715088-1DC2-4BD8-B013-C71C2966861C@zenspider.com> <95590ec2-6bfd-4253-9c26-fe187416dd9c@z9g2000yqz.googlegroups.com> <2A905ED8-53BB-4BFB-8B47-BBDCDB3BCA2A@gmail.com> <6c6a9f3b-5b1f-4879-80d6-de800c6d44c3@f21g2000prn.googlegroups.com> <94E9A201-F4DA-4573-9C6F-FC1980785EA6@gmail.com> <886be148-c01b-472b-8c9a-8efb8a034829@v17g2000prc.googlegroups.com> Message-ID: <6db2312f-340a-4701-b8c4-0a6ba61614c3@a28g2000prb.googlegroups.com> On Dec 1, 4:25?pm, Chad Woolley wrote: > On Wed, Dec 1, 2010 at 1:19 PM, Trans wrote: > > The other option is to just present an error page saying why > > the rdocs could not be generated and what can be done about it. > > If they need sudo access to install the rdoc, won't they also need it > to install the gem files? ?And doesn't that just fail now with a write > permission error? ?Why can't rdoc behave the same way, or is there > something else to consider? Yes, I think you are right. So, I made a nice error page that explains. I just made a pull request for the patch. If you want to try it out, gem install some package with the --no-rdoc option, clone my repo (trans/rubygems) and run `ruby -Ilib bin/gem server`, find the gem and click on the rdoc link. From noreply at rubyforge.org Mon Dec 6 23:06:05 2010 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 6 Dec 2010 23:06:05 -0500 (EST) Subject: [Rubygems-developers] [ rubygems-Bugs-27154 ] Computed hash is sometimes too large. Message-ID: <20101207040605.F27B11858357@rubyforge.org> Bugs item #27154, was opened at 2009-09-21 22:42 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27154&group_id=126 Category: `gem install` command Group: None Status: Open Resolution: None Priority: 3 Submitted By: Ryan Riley (panesofglass) Assigned to: John Barnette (jbarnette) Summary: Computed hash is sometimes too large. Initial Comment: The current hash algorithm in dependency.rb (line 138) and specification.rb (line 658) can sometimes create a hash that is too large. This is also possible with Array#hash in MRI, which can also misbehave if one of the array elements returns a large hash value: class C def hash 100000000000000000000 end end [C.new].hash # => in `hash': bignum too big to convert into `long' (RangeError) REXML has a similar issue. http://redmine.ruby- lang.org/issues/show/1883 tracks the issue, and MRI will be fixing the issue. Suggested fixes are: edit: c:/ruby/libs/ruby/site_ruby/1.8/rubygems/dependency.rb;C840659 File: dependency.rb =================================================================== --- c:/ruby/libs/ruby/site_ruby/1.8/rubygems/dependency.rb;C840659 (server) 6/23/2009 1:21 PM +++ c:/ruby/libs/ruby/site_ruby/1.8/rubygems/dependency.rb @@ -112,7 +112,7 @@ end def hash # :nodoc: - name.hash + type.hash + version_requirements.hash + name.hash ^ type.hash ^ version_requirements.hash end end =================================================================== edit: c:/ruby/libs/ruby/site_ruby/1.8/rubygems/specification.rb;C908357 File: specification.rb =================================================================== --- c:/ruby/libs/ruby/site_ruby/1.8/rubygems/specification.rb;C908357 (server) 6/23/2009 1:24 PM +++ c:/ruby/libs/ruby/site_ruby/1.8/rubygems/specification.rb @@ -661,9 +661,8 @@ private :same_attributes? def hash # :nodoc: - @@attributes.inject(0) { |hash_code, (name, default_value)| - n = self.send(name).hash - hash_code + n + @@attributes.inject(612553) { |hash_code, (name, default_value)| + hash_code ^ self.send(name).hash } end =================================================================== ---------------------------------------------------------------------- Comment By: George Mendoza (gsmendoza) Date: 2010-12-07 12:06 Message: Hello again, I got the bignum error again, but this time with cucumber-0.9.4. These commands weren't able to install the gem: * bundle install * bundle install --local * sudo bundle install --local * sudo bundle install --local --system * sudo bundle install --system However, I was able to work around the issue by 1. installing the gem to my system manually (sudo gem install cucumber --version "0.9.4"), and 2. installing the bundle to the system (sudo bundle install --system) For step 2, trying "bundle install --local" worked only if all the gems in the bundle are already installed. If there were some gems from the bundle that are not installed, running "sudo bundle install --system" was the only way I could install them. George Mendoza Philippines ---------------------------------------------------------------------- Comment By: George Mendoza (gsmendoza) Date: 2010-12-01 11:52 Message: Hello, Appreciate if anybody can re-open this ticket. I am also getting the error when I try to install the dmitryv-backup gem via bundle. Please let me know if I need to provide any other information in order to fix this bug. Thanks! Gemfile: ---------------------------------------- source :rubygems source "http://gems.github.com" #... gem 'dmitryv-backup', '2.4.0', :require => "backup" #... ---------------------------------------- Running: ---------------------------------------- bundle install --local /usr/local/lib/site_ruby/1.8/rubygems/requirement.rb:109:in `hash': bignum too big to convert into `long' (RangeError) from /usr/local/lib/site_ruby/1.8/rubygems/requirement.rb:109:in `hash' from /usr/local/lib/site_ruby/1.8/rubygems/specification.rb:675:in `hash' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/index.rb:36:in `inject' from /usr/local/lib/site_ruby/1.8/rubygems/specification.rb:674:in `each' from /usr/local/lib/site_ruby/1.8/rubygems/specification.rb:674:in `inject' from /usr/local/lib/site_ruby/1.8/rubygems/specification.rb:674:in `hash' from /usr/lib/ruby/1.8/tsort.rb:204:in `include?' from /usr/lib/ruby/1.8/tsort.rb:204:in `each_strongly_connected_component_from' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/spec_set.rb:130:in `tsort_each_child' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/spec_set.rb:130:in `each' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/spec_set.rb:130:in `tsort_each_child' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/spec_set.rb:128:in `each' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/spec_set.rb:128:in `tsort_each_child' from /usr/lib/ruby/1.8/tsort.rb:203:in `each_strongly_connected_component_from' from /usr/lib/ruby/1.8/tsort.rb:209:in `each_strongly_connected_component_from' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/spec_set.rb:130:in `tsort_each_child' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/spec_set.rb:130:in `each' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/spec_set.rb:130:in `tsort_each_child' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/spec_set.rb:128:in `each' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/spec_set.rb:128:in `tsort_each_child' from /usr/lib/ruby/1.8/tsort.rb:203:in `each_strongly_connected_component_from' from /usr/lib/ruby/1.8/tsort.rb:182:in `each_strongly_connected_component' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/spec_set.rb:124:in `tsort_each_node' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/spec_set.rb:124:in `each' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/spec_set.rb:124:in `tsort_each_node' from /usr/lib/ruby/1.8/tsort.rb:180:in `each_strongly_connected_component' from /usr/lib/ruby/1.8/tsort.rb:148:in `tsort_each' from /usr/lib/ruby/1.8/tsort.rb:135:in `tsort' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/spec_set.rb:107:in `sorted' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/spec_set.rb:12:in `each' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/installer.rb:44:in `run' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/installer.rb:8:in `install' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/cli.rb:225:in `install' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/vendor/thor/task.rb:22:in `send' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/vendor/thor/task.rb:22:in `run' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/vendor/thor/invocation.rb:118:in `invoke_task' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/vendor/thor.rb:246:in `dispatch' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/vendor/thor/base.rb:389:in `start' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/bin/bundle:13 from /usr/bin/bundle:19:in `load' from /usr/bin/bundle:19 ---------------------------------------- Thanks, George Mendoza Philippines ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2010-11-13 06:46 Message: This ticket has been deemed stale and we're closing it in order to catch up with our ticket list. If you think it is still valid, please reopen. ---------------------------------------------------------------------- Comment By: Craig Cook (ccook) Date: 2010-10-19 05:08 Message: Hello, I tried this patch, but I am still getting the error, at the same place in the code. The error is the same with or without the patch to specification.rb; dependency.rb was already like the patched part shown above. This happened when installing using bundler, executed via capistrano. We had been using hpricot, it wasn't needed, it was giving this error first. I took it out, but then the same RangeError happened with mysql. I've seen it before also with nokogiri. (Always with native gems, though). Here's the relevant part of the log: ----------- begin log ---------------------------- ** [out :: 192.168.10.63] Installing mysql (2.8.1) ** [out :: 192.168.10.63] with native extensions ** [out :: 192.168.10.62] /usr/lib/ruby/site_ruby/1.8/rubygems/requirement.rb:109:in `hash' ** [out :: 192.168.10.62] : ** [out :: 192.168.10.62] bignum too big to convert into `long' ** [out :: 192.168.10.62] ( ** [out :: 192.168.10.62] RangeError ** [out :: 192.168.10.62] ) ** [out :: 192.168.10.62] from /usr/lib/ruby/site_ruby/1.8/rubygems/requirement.rb:109:in `hash' ** [out :: 192.168.10.62] from /usr/lib/ruby/site_ruby/1.8/rubygems/specification.rb:675:in `hash' ** [out :: 192.168.10.62] from /usr/lib/ruby/1.8/fileutils.rb:243:in `inject' ** [out :: 192.168.10.62] from /usr/lib/ruby/site_ruby/1.8/rubygems/specification.rb:674:in `each' ** [out :: 192.168.10.62] from /usr/lib/ruby/site_ruby/1.8/rubygems/specification.rb:674:in `inject' ** [out :: 192.168.10.62] from /usr/lib/ruby/site_ruby/1.8/rubygems/specification.rb:674:in `hash' ** [out :: 192.168.10.62] from /usr/lib/ruby/1.8/tsort.rb:205:in `include?' ** [out :: 192.168.10.62] from /usr/lib/ruby/1.8/tsort.rb:205:in `each_strongly_connected_component_from' ** [out :: 192.168.10.62] ... 22 levels... ** [out :: 192.168.10.62] from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.2/lib/bundler/vendor/thor/base.rb:389:in `start' ** [out :: 192.168.10.62] from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.2/bin/bundle:13 ** [out :: 192.168.10.62] from /usr/bin/bundle:19:in `load' ** [out :: 192.168.10.62] from /usr/bin/bundle:19 ----------- end cap output ------------------- running: ------------ system & ruby info ------------------ [ccook at ev2-stage ~]$ ruby -v ruby 1.8.7 (2010-08-16 patchlevel 302) [i686-linux] [ccook at ev2-stage ~]$ gem -v 1.3.7 [ccook at ev2-stage ~]$ uname -a Linux ev2-stage 2.6.18-194.11.4.el5xen #1 SMP Tue Sep 21 06:28:04 EDT 2010 i686 i686 i386 GNU/Linux ------ end system / ruby info ---------- Gemfile: ----------- begin Gemfile ----------------- source :gemcutter gem 'rails', '2.3.8' gem 'mysql', '2.8.1' gem "geokit" gem "geokit-rails" gem "builder" gem 'chronic' gem 'whenever' gem 'database_cleaner' gem 'apn_on_rails' gem 'factory_girl' gem 'net-sftp' gem 'will_paginate' # dependency for squirrel & jqgrid gem 'nokogiri' # only for test/functional/auth_controller_test.rb gem 'cucumber' gem 'cucumber-rails' gem 'webrat' gem 'rspec' ---------- end Gemfile ----------------- So, is this the same issue? It sure looks like it to me. I hope not to have to dive into the innards of rubygems if possible. But we need to be able to deploy. The app is working and passing tests on development, but hard to say on staging as we can't get it over there with cap. I suppose it could all be done by hand once anyway, but we (other dev on my team and I ) need to be able to do this over again. Thanks for your time in this! Cheers, Craig ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27154&group_id=126 From noreply at rubyforge.org Wed Dec 8 17:52:59 2010 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 8 Dec 2010 17:52:59 -0500 (EST) Subject: [Rubygems-developers] [ rubygems-Bugs-28774 ] inline.rb:365:in `module_name': undefined method `gsub' for nil:NilClass (NoMethodError) Message-ID: <20101208225259.5AB6D19782CD@rubyforge.org> Bugs item #28774, was opened at 2010-12-08 16:52 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28774&group_id=126 Category: #gem and #require methods Group: next Status: Open Resolution: None Priority: 3 Submitted By: Fernando Flores Oviedo (luisflores1961) Assigned to: Nobody (None) Summary: inline.rb:365:in `module_name': undefined method `gsub' for nil:NilClass (NoMethodError) Initial Comment: luisflores at luisflores-laptop:~$ ruby Inlinelearning.rb /usr/local/lib/ruby/gems/1.9.1/gems/RubyInline-3.8.6/lib/inline.rb:365:in `module_name': undefined method `gsub' for nil:NilClass (NoMethodError) from /usr/local/lib/ruby/gems/1.9.1/gems/RubyInline-3.8.6/lib/inline.rb:375:in `so_name' from /usr/local/lib/ruby/gems/1.9.1/gems/RubyInline-3.8.6/lib/inline.rb:498:in `load_cache' from /usr/local/lib/ruby/gems/1.9.1/gems/RubyInline-3.8.6/lib/inline.rb:827:in `inline' from Inlinelearning.rb:16:in `singletonclass' from Inlinelearning.rb:15:in `' from Inlinelearning.rb:14:in `
' running Ruby version ruby 1.9.2p0 (2010-08-18 revision 29036) [i686-linux] Please help ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28774&group_id=126 From transfire at gmail.com Wed Dec 8 18:12:26 2010 From: transfire at gmail.com (Trans) Date: Wed, 8 Dec 2010 15:12:26 -0800 (PST) Subject: [Rubygems-developers] Contributing to Ruby Projects Message-ID: I would like some constructive appraisal. I recently offered some patches to RubyGems. I feel I was making my best effort to contribute some functionality to the code base that would be useful to developers. But in this process, rather then feel a part of a community effort, even if only a minor part, I felt rather skewered... https://github.com/rubygems/rubygems/pull/14 (above in context https://github.com/trans/rubygems/commit/b61fd7cb577a8df6be2feb1a35983e9846d31b3c) https://github.com/rubygems/rubygems/pull/12 https://github.com/rubygems/rubygems/pull/8 I'm not sure why anyone would contribute to a Ruby project if it transpires like this. But then maybe thats the way it is? Is this really what one should expect? From thewoolleyman at gmail.com Wed Dec 8 19:23:17 2010 From: thewoolleyman at gmail.com (Chad Woolley) Date: Wed, 8 Dec 2010 17:23:17 -0700 Subject: [Rubygems-developers] Contributing to Ruby Projects In-Reply-To: References: Message-ID: On Wed, Dec 8, 2010 at 4:12 PM, Trans wrote: > I would like some constructive appraisal. I recently offered some > patches to RubyGems. I feel I was making my best effort to contribute > some functionality to the code base that would be useful to > developers. But in this process, rather then feel a part of a > community effort, even if only a minor part, I felt rather skewered... > > ?https://github.com/rubygems/rubygems/pull/14 > ?(above in context https://github.com/trans/rubygems/commit/b61fd7cb577a8df6be2feb1a35983e9846d31b3c) > ?https://github.com/rubygems/rubygems/pull/12 > ?https://github.com/rubygems/rubygems/pull/8 > > I'm not sure why anyone would contribute to a Ruby project if it > transpires like this. But then maybe thats the way it is? Is this > really what one should expect? 1. Ruby != Ryan, Eric, and Luis 2. Looks to me like they took a lot of time giving you constructive feedback, albiet abrasive. Take the feedback, stay calm, and keep trying. Or, if that isn't possible, contribute to a Ruby project where your commits don't have to be reviewed by these people. They aren't always the nicest, but they have worked on RubyGems a lot so you should take their suggestions unless you can make a REALLY good argument otherwise. 3. Ryan and Eric often handle conflict and criticism by not responding at all (which is funny as hell, unless it's you). You should feel lucky you got all this detailed feedback ;) -- Chad From noreply at rubyforge.org Wed Dec 8 20:44:54 2010 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 8 Dec 2010 20:44:54 -0500 (EST) Subject: [Rubygems-developers] [ rubygems-Bugs-28774 ] inline.rb:365:in `module_name': undefined method `gsub' for nil:NilClass (NoMethodError) Message-ID: <20101209014454.CF5431858346@rubyforge.org> Bugs item #28774, was opened at 2010-12-08 14:52 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28774&group_id=126 Category: #gem and #require methods Group: next >Status: Closed >Resolution: Rejected Priority: 3 Submitted By: Fernando Flores Oviedo (luisflores1961) Assigned to: Nobody (None) Summary: inline.rb:365:in `module_name': undefined method `gsub' for nil:NilClass (NoMethodError) Initial Comment: luisflores at luisflores-laptop:~$ ruby Inlinelearning.rb /usr/local/lib/ruby/gems/1.9.1/gems/RubyInline-3.8.6/lib/inline.rb:365:in `module_name': undefined method `gsub' for nil:NilClass (NoMethodError) from /usr/local/lib/ruby/gems/1.9.1/gems/RubyInline-3.8.6/lib/inline.rb:375:in `so_name' from /usr/local/lib/ruby/gems/1.9.1/gems/RubyInline-3.8.6/lib/inline.rb:498:in `load_cache' from /usr/local/lib/ruby/gems/1.9.1/gems/RubyInline-3.8.6/lib/inline.rb:827:in `inline' from Inlinelearning.rb:16:in `singletonclass' from Inlinelearning.rb:15:in `' from Inlinelearning.rb:14:in `
' running Ruby version ruby 1.9.2p0 (2010-08-18 revision 29036) [i686-linux] Please help ---------------------------------------------------------------------- >Comment By: Ryan Davis (zenspider) Date: 2010-12-08 17:44 Message: This has nothing to do with rubygems and everything to do with my RubyInline gem. Please file the same bug on my tracker at: http://rubyforge.org/tracker/?atid=1774&group_id=440&func=browse and please provide enough code that I can reproduce it. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28774&group_id=126 From jftucker at gmail.com Wed Dec 8 20:46:56 2010 From: jftucker at gmail.com (James Tucker) Date: Wed, 8 Dec 2010 17:46:56 -0800 Subject: [Rubygems-developers] Contributing to Ruby Projects In-Reply-To: References: Message-ID: <7A18FA67-CAEC-4853-8FD2-56EBD0EB8514@gmail.com> On Dec 8, 2010, at 3:12 PM, Trans wrote: > I would like some constructive appraisal. I recently offered some > patches to RubyGems. I feel I was making my best effort to contribute > some functionality to the code base that would be useful to > developers. But in this process, rather then feel a part of a > community effort, even if only a minor part, I felt rather skewered... > > https://github.com/rubygems/rubygems/pull/14 > (above in context https://github.com/trans/rubygems/commit/b61fd7cb577a8df6be2feb1a35983e9846d31b3c) > https://github.com/rubygems/rubygems/pull/12 > https://github.com/rubygems/rubygems/pull/8 > > I'm not sure why anyone would contribute to a Ruby project if it > transpires like this. But then maybe thats the way it is? Changes to the specification format must be done with care that you don't introduce odd edge cases or bad practices that have already been worked out for good reasons. As stated by Chad, whilst the comments may have become abrasive, the core content contains valid points. I don't see how you would expect these points to be ignored just because you wrote a patch. I will come and provide some more feedback if/when I have time to, at present I don't have time to. > Is this > really what one should expect? You should expect review. You should not expect review to happen definitely within some specific time period (as per pull/8). This is open source, I'm certainly not paid to work on any open source. I can't speak for history that clearly has an effect on the kind of responses you got from individuals. I can tell you that in the very limited time I've had to look through this, there are valid comments that prevent a merge into master at this time for at least the gemspec changesets. I haven't had time to review the rdoc changesets. From jbarnette at gmail.com Thu Dec 9 00:04:37 2010 From: jbarnette at gmail.com (John Barnette) Date: Wed, 8 Dec 2010 21:04:37 -0800 Subject: [Rubygems-developers] Contributing to Ruby Projects In-Reply-To: References: Message-ID: On Dec 8, 2010, at 3:12 PM, Trans wrote: > I would like some constructive appraisal. I recently offered some > patches to RubyGems. I feel I was making my best effort to contribute > some functionality to the code base that would be useful to > developers. But in this process, rather then feel a part of a > community effort, even if only a minor part, I felt rather skewered... > > https://github.com/rubygems/rubygems/pull/14 > (above in context https://github.com/trans/rubygems/commit/b61fd7cb577a8df6be2feb1a35983e9846d31b3c) > https://github.com/rubygems/rubygems/pull/12 > https://github.com/rubygems/rubygems/pull/8 > > I'm not sure why anyone would contribute to a Ruby project if it > transpires like this. But then maybe thats the way it is? Is this > really what one should expect? Sorry it took so long to respond, I had to do some reading. The comments are rude. They are also accurate. It's not how I'd ever speak to someone online, but I don't disagree with any of the substantive points. I'd like to see them addressed before these get merged. ~ j. From luislavena at gmail.com Thu Dec 9 10:08:13 2010 From: luislavena at gmail.com (Luis Lavena) Date: Thu, 9 Dec 2010 12:08:13 -0300 Subject: [Rubygems-developers] Contributing to Ruby Projects In-Reply-To: References: Message-ID: On Wed, Dec 8, 2010 at 9:23 PM, Chad Woolley wrote: > On Wed, Dec 8, 2010 at 4:12 PM, Trans wrote: >> I would like some constructive appraisal. I recently offered some >> patches to RubyGems. I feel I was making my best effort to contribute >> some functionality to the code base that would be useful to >> developers. But in this process, rather then feel a part of a >> community effort, even if only a minor part, I felt rather skewered... >> >> ?https://github.com/rubygems/rubygems/pull/14 >> ?(above in context https://github.com/trans/rubygems/commit/b61fd7cb577a8df6be2feb1a35983e9846d31b3c) >> ?https://github.com/rubygems/rubygems/pull/12 >> ?https://github.com/rubygems/rubygems/pull/8 >> >> I'm not sure why anyone would contribute to a Ruby project if it >> transpires like this. But then maybe thats the way it is? Is this >> really what one should expect? > > 1. Ruby != Ryan, Eric, and Luis > Thank you for that Chad. I don't consider myself been Ruby, so thanks for clarifying that. Leaving the joke aspect out for a moment, not going to defend Ryan comments as they were childish and offensive. I had my share of these comments in the past with him, but I learnt just to ignore them and let my code speak for me (not saying that I'm the best Ruby coder ever). Back to the points there, I asked specifically about Gem::Resource rationale/purpose as was not expressed in the pull request, nor in the commits, nor in the tests. I believe my question, while naive, was not made with bad intentions. While Trans mention users "want" something, I'm having problems find the references of that functionality been used or wanted by others. Perhaps there is, but was not provided as reference. For example, this pull request: https://github.com/rubygems/rubygems/pull/8 Was valid, well covered and already discussed over this list. The only request made by John was have these changes in a branch. You can't say that these comments or things discussed in the list weren't constructive to it. The other comments, between all the unacceptable way of communicating disagreement between human beings had some valid points. That was the only part I would consider when looking back to this topic. -- 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 jon.forums at gmail.com Thu Dec 9 12:33:22 2010 From: jon.forums at gmail.com (Jon) Date: Thu, 9 Dec 2010 12:33:22 -0500 Subject: [Rubygems-developers] Contributing to Ruby Projects In-Reply-To: References: Message-ID: <20101209123322.b57de525.jon.forums@gmail.com> > I would like some constructive appraisal. I recently offered some > patches to RubyGems. I feel I was making my best effort to contribute > some functionality to the code base that would be useful to > developers. But in this process, rather then feel a part of a > community effort, even if only a minor part, I felt rather skewered... > > https://github.com/rubygems/rubygems/pull/14 > (above in context https://github.com/trans/rubygems/commit/b61fd7cb577a8df6be2feb1a35983e9846d31b3c) > https://github.com/rubygems/rubygems/pull/12 > https://github.com/rubygems/rubygems/pull/8 > > I'm not sure why anyone would contribute to a Ruby project if it > transpires like this. But then maybe thats the way it is? Is this > really what one should expect? Since you explicitly asked for some constructive appraisal, IMO your email is as out-of-place on this developer list as http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/19349 was on the ruby-core list. After rerereading the comments, I came away with a vastly different impression than you must have. While the comments were frank and direct, I was especially impressed with the amount of detail from Eric. I'm guessing Ryan's comment to 14 combined with the history between between you two made the overall comments feel more aggressive than they appeared to me. While we all have different styles, I do think Ryan gave you valuable feedback in his comment. Rather than combining three different, yet related, issues (community contributions, feedback style and status request as to your patches) into one email, you may have been better served to focus on the status update request in your email to this developer list while trying to work any personal issues offline directly with Ryan and Eric. Both Chad and John B's responses are some of the wisest and most constructive I've seen in a long time. Jon --- http://jonforums.github.com/ From drbrain at segment7.net Fri Dec 10 01:55:20 2010 From: drbrain at segment7.net (Eric Hodel) Date: Thu, 9 Dec 2010 22:55:20 -0800 Subject: [Rubygems-developers] Contributing to Ruby Projects In-Reply-To: References: Message-ID: On Dec 8, 2010, at 15:12, Trans wrote: > I would like some constructive appraisal. I recently offered some > patches to RubyGems. I feel I was making my best effort to contribute > some functionality to the code base that would be useful to > developers. But in this process, rather then feel a part of a > community effort, even if only a minor part, I felt rather skewered? To begin with I would like to point out that you have deleted several of your comments forcing me to respond from memory and leaving their contents at the risk of "he-said, she-said". I have reordered these pull requests chronologically. > https://github.com/rubygems/rubygems/pull/8 I'm not sure what your complaint is here. The request is reasonable but you have not acted on it. It is your job to make your pull requests acceptable for contribution. > https://github.com/rubygems/rubygems/pull/12 Since you have deleted your comment stream I'll have to reconstruct your counter-arguments from memory. I have them out of order because this email is already up to 5K of text and I don't think it's worth my time to order them properly. I rejected plain-YAML gemspecs because it is not a type-safe data format, and that it increases maintenance burden of future RubyGems versions for the benefit of a small minority of users. I don't see anything unfair about this assessment. I asked if there were any non-ruby tools that used a YAML gemspec. If such a tool existed it might be a reason to consider this feature. You did not name any non-ruby tools that used a YAML gemspec, but you came up with some hypothetical ruby tools that could use this feature. You claimed that this feature was important because either RubyGems consumed too many resources or that it would not be available. In brief, I responded that if it's a ruby tool it can use RubyGems and that RubyGems resource burden is not too large. As of Ruby 1.9 RubyGems is always available. (Adding a feature to RubyGems specifically for Ruby 1.8 requires an overwhelming need.) I believe this is where I closed the ticket as you could not come up with a satisfactory reason for including plain-YAML gemspecs. You persisted, however and I continued to respond. You argued that it could be made "safer" and I referenced the past history of junk data in gemspecs and Jeremy Hindegardener's talk at RubyConf 2010 as a demonstration that it probably can't be made safer. You said it would be "more convenient" and I responded that I could not find a gem that used YAML in its .gemspec file in a few minutes of searching. I pointed out that the community has decided that the de-facto format for gemspec files is Ruby. I thought you would take my lack of discovery of YAML .gemspec files as an opportunity to show me a single project that used YAML in its gemspecs. This would demonstrate there was even a handful of RubyGems users who would benefit from this feature but you did not (or could not?). You pointed out ore which uses plain-YAML to create gemspecs and gems and used it as an argument in your favor. I responded that if ore supports this you should use ore as it does what you want already and requires no changes to RubyGems. Since you did not demonstrate that there was another RubyGems user who desires plain-YAML gemspecs I responded that there is only one person that wants this feature and that was not enough users to include it. I reiterated that the community has decided they prefer ruby. If you look at the download counts, people overwhelmingly prefer to use ruby to build gems. Hoe has 690,000 and Jeweler has 56,000. Ore has 453. You claimed that I did not understand the intent of your feature, but I was perfectly clear on that as both your initial description and the content of your patch were perfectly clear. For a feature to be added to RubyGems one of the requirements is that it cannot be implemented outside RubyGems. Ore shows that it is possible to implement this feature outside of RubyGems. I now have a full page and over 1.5k of summary in this email of our conversation past the point where I closed the issue. We had a long and thorough discussion of the issue but you could not bring up any reason for inclusion of plain-YAML gemspecs. I believe that my conduct in our conversation was fair and reasonable and that any unbiased reader would find it so. Again, your request for plain-YAML gemspecs is not suitable for inclusion in RubyGems It is not type-safe. It benefits a single user. It is adequately covered by functionality outside of RubyGems It increases the maintenance burden of RubyGems. If it were Dave Thomas, Chad Fowler, Jim Weirich or anyone else who had suggested this feature I would reject it for exactly these reasons as well. > https://github.com/rubygems/rubygems/pull/14 I gave you a frank assessment, approving your idea but rejecting your implementation, specifically of Gem::Resource. I recommended a Hash instead as it avoids the high run-time cost (which must be paid every time an installed gem is activated): > It appears that a resources Hash on Gem::Specification would be a better solution. This implementation requires triple-dispatch. (Gem::Specification#add_resource => Gem::Resource#add_resource => #resource_name => Hash#[]= vs Gem::Specification#add_resource => Hash#[]=) You refused to budge on Gem::Resource saying the aliases were provided for convenience. You said your patch was not 100% complete. I rejected aliases again, I explained how to perform a feature-check for #add_resource (which is currently implemented for several things in #to_ruby) and pointed out that your tests do not require what you claimed to. I asked why you created a pull request if your code wasn't ready for commit. If you wish to have your idea reviewed you should come here to the mailing list. If you wish to have your incomplete implementation reviewed you should come here to the mailing list. You also continued to claim that Gem::Resource#hash and #eql? were required despite my statement that I had applied your patch, deleted these methods and had a successful run. In all, despite rejecting aliases and the implementation that required them you continued to fight for them, refusing to come to any compromise. Now that I have reviewed this again I have another reason to reject your implementation, the Ruby gemspec is run at gem load time and the creation of a new object and multiple-dispatch to set fields in it will be too slow in comparison to a simple hash. As I stated, your idea is great and had been discussed prior to submitted your pull request. Your implementation of Gem::Resource is rejected. It is too slow compared to a Hash and does not provide enough benefit. Gem::Specification#add_resource is great and fits well with existing Gem::Specification methods. At this point it's hard for me to determine what you are expecting. > I'm not sure why anyone would contribute to a Ruby project if it transpires like this. But then maybe thats the way it is? As I said in pull request 12: RubyGems is a core component of the ruby community. Due to its core position it needs to have a conservative policy towards improvements and those improvements that are accepted need to have simple, concise and easy to maintain implementations. It is unreasonable to expect an admittedly incomplete patch would be accepted immediately. It is unreasonable to believe that an patch submitted to RubyGems would not undergo a thorough and critical review. When given a review it is your obligation to come to a compromise but you refuse to budge. You claim you were not given enough time to budge, but you were amply active in replying to my commentary for the past two days, and I have spent 10s of kilobytes and hours of time attempting to explain why your patches were rejected and what would make them acceptable. I will now respond to the remainder of the last comment on pull request 12: https://github.com/rubygems/rubygems/pull/12#issuecomment-601579 > What do you mean I didn't budge? I was trying to discuss the issue, and you all get in a dither over it. (I mean really, consider one of the first things you did was make a sharply worded remark about not changing style because I dropped a then from an if. Which I later discover, btw, isn't a RubyGems code style at all b/c then isn't used in many places. It is not worth our time to update the style on every file. If you check the history you will see that older RubyGems codes does not use then. It is required now. I believe there is another pull request mentioning this but it has been over three hours since I started writing this email now and I am can't be bothered to find it. > And don't even get me started on Ryan. That asshole spends his time cursing at me on every other line for anything at all, like using inject (heaven forbid!) or putting a blank comment line which I use as a device as a reminder to go back and write docs. It's absolutely ridiculous. And unworthy of an important project like Rubygems. Ryan may have been harsh in his critique of your code, but I don't recall he gave you any less critique than he did for the students he taught at the UW extension course. I don't recall that Ryan has ever called you an asshole. I'm know you are aware that Ryan and I work together on a daily basis, and I am certain that you have formed opinions of Ryan's opinion of you. I will clarify that this includes any private conversations we have had. (Knowing Ryan as we both do, however, this will change tomorrow when we meet.) > The fact is I was only ever providing my take on the matter, why I was seeking to do it that way, I worked on it as part of what I'd like to see in RubyGems. I don't work for you. You are not my employer. I submitted patches that were geared toward use cases that I would make of RubyGems. Why would I do anything else? I don't doubt the sincerity of your commits. I gave what I felt was a fair consideration of your ideas and responded appropriately. > Right or wrong, you guys didn't even allow for appropriate time to "budge". I consider two days of response on pull request 12 to be adequate time. I consider your frequent responses on pull request 14 to be adequate time. > All you and Ryan wanted to do was for me to say "yes sir, sorry sir! Hop to, sir. I'll have those "fixes" to you by morning". I don't care how long you take. If you wish to stop and think about something then go ahead. I'm not sure what you wish to imply with your quotes around "fixes". Perhaps you mean my reasoning was illogical, but I believe I gave you logical reasons for rejection. Perhaps you are mocking me, I find that amusing. Perhaps you just don't understand that your code was not acceptable despite me going to great pains to explain how and why it was not. > We'll forget it. You all can enjoy YOUR "open source" project. I do not "contribute to open source" project run by assholes. And now you have insulted me. > And honestly I am sorry if I am putting more of this on you right now then you probably deserve. Ryan really is ten times worse. None the less this has been a wholly frustrating experience. And I can only think that ultimately these kinds of things will be very bad for Ruby in general. You are putting more of this on me than I deserve, and it's unfair. I've spent hours of my time trying to show you what was unacceptable in your patches and you have refused to acknowledge a single point. Now you're sending an email to the list to garner sympathy. I've now spent nearly four hours writing this response. You think you're frustrated? > Go ahead and blame we all you want. I don't calm to be wholly innocent. But I do know that all I did was earnestly try to contribute to the improvement of Gems and was essentially eviscerated for my troubles. No, you did not try to earnestly contribute. As soon as you sensed the slightest bit of resistance you immediately became defensive. You refused to budge on anything. This is not how you behave if you want to contribute. I did not eviscerate you, I gave your patches and ideas a critical review. It seems that you do not understand what a critical review is. You may not like it. I have gone through many and I did not like them either, but they have helped me become a better programmer. > Is this really what one should expect? It appears you have decided my rejection of 12 and 14 was because I have some personal vendetta against you. I believe I gave your ideas a fair consideration and commented on them accordingly. Not every change submitted can be included in RubyGems. In one of your comments on pull request 12 you said something like: > Necessity is the mother of invention, but everyone who has used a remote control knows that convenience is where it's at. To which I responded: > PS: Restrict yourself to technical merits and avoid editorializing. The pull request comments are here for the discussion of utility, usability and maintainability of proposed changes. They are not to make undecipherable editorial comments centered on necessity, invention and remote controls. It appears you don't actually want to have a discussion on the grounds of utility, usability or maintainability but instead you wish to be right and you wish to get your way. Whenever I would counter one of your arguments you would shift to a new different argument. When I exhausted all those you claimed I didn't understand you despite understanding you perfectly clearly. Finally you attempt to appeal to this list to garner sympathy. Your evasive behavior and martyrdom are exceptionally frustrating. Despite the deletion of the majority of your commentary in the pull requests which should reasonably explain the reasons for my frustration, I am again going to say that when you don't get your way you present yourself as a martyr and throw a fit as you have done in this instance. Throwing a fit when you don't get your way is a behavior most people have grown out of by the time they're 10. You're three times that age now. I tried to give you the benefit of the doubt when you submitted your pull requests. I hope that my comments here and on the pull requests adequately show that to the other readers of this email and this list. You've reacted exactly this way before and, unfortunately, you will probably continue to do so. Based on your behavior I'm not certain I wish to continue to review your contributions without rejecting them outright. It certainly isn't worth my time as I've lost an entire day of productive work dealing with your attempt at martyrdom (four hours on this email alone). I can only hope that you will actually stop contributing. Sincerely, Eric Hodel The "asshole" PS: I'm not going to respond to any of your further emails on this thread, so feel free to call me whatever additional names you like! From jbarnette at gmail.com Fri Dec 10 15:35:47 2010 From: jbarnette at gmail.com (John Barnette) Date: Fri, 10 Dec 2010 12:35:47 -0800 Subject: [Rubygems-developers] Pull Requests Message-ID: All, We have six open pull requests in https://github.com/organizations/rubygems/dashboard/pulls and I'll like to look at merging them. Please pile on to the comments over there. Silence is consent. :) ~ j. From luislavena at gmail.com Fri Dec 10 17:16:08 2010 From: luislavena at gmail.com (Luis Lavena) Date: Fri, 10 Dec 2010 19:16:08 -0300 Subject: [Rubygems-developers] Pull Requests In-Reply-To: References: Message-ID: On Fri, Dec 10, 2010 at 5:35 PM, John Barnette wrote: > All, > > We have six open pull requests in https://github.com/organizations/rubygems/dashboard/pulls and I'll like to look at merging them. Please pile on to the comments over there. Silence is consent. :) > I'm working on pull #2: https://github.com/rubygems/rubygems/pull/2 As I would like to offer similar interface and hooking as progress_report UI elements. That way, on non-tty interfaces \r is not generated. Need some inspiration ;-) -- 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 devnull+rubygems-ci at pivotallabs.com Fri Dec 10 17:27:43 2010 From: devnull+rubygems-ci at pivotallabs.com (devnull+rubygems-ci at pivotallabs.com) Date: Fri, 10 Dec 2010 22:27:43 +0000 Subject: [Rubygems-developers] [CruiseControl] RubyGemsGitHub build aff8c2c failed Message-ID: <4d02a95f247f2_7270..fdbe313802534@ci.pivotallabs.com.tmail> The build failed. CHANGES ------- Revision ...aff8c2c0698e11a8d421c9a99bdea5ca553f0240 committed by Jeff Wallace on 2010-11-27 05:45:01 Simplify DependencyList#active_count. lib/rubygems/dependency_list.rb | 8 +------- 1 files changed, 1 insertions(+), 7 deletions(-) TEST FAILURES AND ERRORS ----------------------- Name: test_active_count(TestGemDependencyList) Type: Error Message: NoMethodError: undefined method `count' for []:Array /home/pivotal/.cruise/projects/RubyGemsGitHub/work/test/../lib/rubygems/dependency_list.rb:205:in `active_count' ./test/test_gem_dependency_list.rb:37:in `send' ./test/test_gem_dependency_list.rb:37:in `test_active_count' /usr/local/lib/ruby/gems/1.8/gems/minitest-1.5.0/lib/minitest/unit.rb:458:in `__send__' /usr/local/lib/ruby/gems/1.8/gems/minitest-1.5.0/lib/minitest/unit.rb:458:in `run' /usr/local/lib/ruby/gems/1.8/gems/minitest-1.5.0/lib/minitest/unit.rb:426:in `run_test_suites' /usr/local/lib/ruby/gems/1.8/gems/minitest-1.5.0/lib/minitest/unit.rb:420:in `each' /usr/local/lib/ruby/gems/1.8/gems/minitest-1.5.0/lib/minitest/unit.rb:420:in `run_test_suites' /usr/local/lib/ruby/gems/1.8/gems/minitest-1.5.0/lib/minitest/unit.rb:419:in `each' /usr/local/lib/ruby/gems/1.8/gems/minitest-1.5.0/lib/minitest/unit.rb:419:in `run_test_suites' /usr/local/lib/ruby/gems/1.8/gems/minitest-1.5.0/lib/minitest/unit.rb:393:in `run' /usr/local/lib/ruby/gems/1.8/gems/minitest-1.5.0/lib/minitest/unit.rb:334:in `autorun' See http://ci.pivotallabs.com:3333/builds/RubyGemsGitHub/aff8c2c0698e11a8d421c9a99bdea5ca553f0240 for details. From devnull+rubygems-ci at pivotallabs.com Fri Dec 10 17:33:18 2010 From: devnull+rubygems-ci at pivotallabs.com (devnull+rubygems-ci at pivotallabs.com) Date: Fri, 10 Dec 2010 22:33:18 +0000 Subject: [Rubygems-developers] [CruiseControl] RubyGemsGitHub build ad17f92 failed Message-ID: <4d02aaaeb8088_7270..fdbe3138026c1@ci.pivotallabs.com.tmail> The build failed. CHANGES ------- Revision ...ad17f92a5bd24ec955e16eff613a70c3786e1191 committed by Aiden Nibali on 2010-11-07 22:32:23 Improved thread safety in remote fetcher lib/rubygems/remote_fetcher.rb | 2 +- test/test_gem_remote_fetcher.rb | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) TEST FAILURES AND ERRORS ----------------------- Name: test_active_count(TestGemDependencyList) Type: Error Message: NoMethodError: undefined method `count' for []:Array /home/pivotal/.cruise/projects/RubyGemsGitHub/work/test/../lib/rubygems/dependency_list.rb:205:in `active_count' ./test/test_gem_dependency_list.rb:37:in `send' ./test/test_gem_dependency_list.rb:37:in `test_active_count' /usr/local/lib/ruby/gems/1.8/gems/minitest-1.5.0/lib/minitest/unit.rb:458:in `__send__' /usr/local/lib/ruby/gems/1.8/gems/minitest-1.5.0/lib/minitest/unit.rb:458:in `run' /usr/local/lib/ruby/gems/1.8/gems/minitest-1.5.0/lib/minitest/unit.rb:426:in `run_test_suites' /usr/local/lib/ruby/gems/1.8/gems/minitest-1.5.0/lib/minitest/unit.rb:420:in `each' /usr/local/lib/ruby/gems/1.8/gems/minitest-1.5.0/lib/minitest/unit.rb:420:in `run_test_suites' /usr/local/lib/ruby/gems/1.8/gems/minitest-1.5.0/lib/minitest/unit.rb:419:in `each' /usr/local/lib/ruby/gems/1.8/gems/minitest-1.5.0/lib/minitest/unit.rb:419:in `run_test_suites' /usr/local/lib/ruby/gems/1.8/gems/minitest-1.5.0/lib/minitest/unit.rb:393:in `run' /usr/local/lib/ruby/gems/1.8/gems/minitest-1.5.0/lib/minitest/unit.rb:334:in `autorun' See http://ci.pivotallabs.com:3333/builds/RubyGemsGitHub/ad17f92a5bd24ec955e16eff613a70c3786e1191 for details. From ryand-ruby at zenspider.com Fri Dec 10 18:03:09 2010 From: ryand-ruby at zenspider.com (Ryan Davis) Date: Fri, 10 Dec 2010 15:03:09 -0800 Subject: [Rubygems-developers] Pull Requests In-Reply-To: References: Message-ID: <4B44EA34-A0C6-43A5-A430-B27DA9ACDC8D@zenspider.com> On Dec 10, 2010, at 12:35 , John Barnette wrote: > All, > > We have six open pull requests in https://github.com/organizations/rubygems/dashboard/pulls and I'll like to look at merging them. Please pile on to the comments over there. Silence is consent. :) I've closed or applied all but 3: + 2 of which are deferred to luis. + 1 needs some work. From devnull+rubygems-ci at pivotallabs.com Fri Dec 10 19:59:18 2010 From: devnull+rubygems-ci at pivotallabs.com (devnull+rubygems-ci at pivotallabs.com) Date: Sat, 11 Dec 2010 00:59:18 +0000 Subject: [Rubygems-developers] [CruiseControl] RubyGemsGitHub build 5a478ec failed Message-ID: <4d02cce6d5d4_7270..fdbe313802770@ci.pivotallabs.com.tmail> The build failed. CHANGES ------- Revision ...5a478ecdf462be68f7872ef1d7ac2f183e84ffbd committed by Luis Lavena on 2010-12-11 00:51:46 Update ChangeLog to reflect merge commits ChangeLog | 7 +++++++ 1 files changed, 7 insertions(+), 0 deletions(-) Revision ...5cf354d33902d13da9b6f633f40ae5bd4d84a9c5 committed by Luis Lavena on 2010-12-11 00:48:29 Minor tweaks to pull request for test pass Also tweak messaging and help options lib/rubygems/commands/server_command.rb | 4 ++-- lib/rubygems/server.rb | 12 +++++++----- 2 files changed, 9 insertions(+), 7 deletions(-) Revision ...c9ef20cf18c748fb83733ab9dee196acff7d245a committed by Luis Lavena on 2010-12-11 00:33:08 Merge branch 'gem_server_launch' of https://github.com/vertiginous/rubygems into vertiginous-gem_server_launch Revision ...e47243c41f43f0b50c8a13302a53cf9cc97406e4 committed by Gordon Thiesfeld on 2010-12-05 18:18:05 added help information for gem server --launch lib/rubygems/commands/server_command.rb | 4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) Revision ...585ee90fa289baee2e58c0ff897570c4fb4a0b67 committed by Gordon Thiesfeld on 2010-12-05 17:52:05 gave --launch an optional argument so the user can define the command used to open the browswer lib/rubygems/commands/server_command.rb | 4 +++- lib/rubygems/server.rb | 3 +-- 2 files changed, 4 insertions(+), 3 deletions(-) Revision ...28822b581aa5645d7dd6247bd5e49c72c389635f committed by Gordon Thiesfeld on 2010-12-05 15:38:10 added gem server --launch option to launch a browser pointing at gem server lib/rubygems/commands/server_command.rb | 4 ++++ lib/rubygems/server.rb | 16 ++++++++++++++-- 2 files changed, 18 insertions(+), 2 deletions(-) TEST FAILURES AND ERRORS ----------------------- Name: test_active_count(TestGemDependencyList) Type: Error Message: NoMethodError: undefined method `count' for []:Array /home/pivotal/.cruise/projects/RubyGemsGitHub/work/test/../lib/rubygems/dependency_list.rb:205:in `active_count' ./test/test_gem_dependency_list.rb:37:in `send' ./test/test_gem_dependency_list.rb:37:in `test_active_count' /usr/local/lib/ruby/gems/1.8/gems/minitest-1.5.0/lib/minitest/unit.rb:458:in `__send__' /usr/local/lib/ruby/gems/1.8/gems/minitest-1.5.0/lib/minitest/unit.rb:458:in `run' /usr/local/lib/ruby/gems/1.8/gems/minitest-1.5.0/lib/minitest/unit.rb:426:in `run_test_suites' /usr/local/lib/ruby/gems/1.8/gems/minitest-1.5.0/lib/minitest/unit.rb:420:in `each' /usr/local/lib/ruby/gems/1.8/gems/minitest-1.5.0/lib/minitest/unit.rb:420:in `run_test_suites' /usr/local/lib/ruby/gems/1.8/gems/minitest-1.5.0/lib/minitest/unit.rb:419:in `each' /usr/local/lib/ruby/gems/1.8/gems/minitest-1.5.0/lib/minitest/unit.rb:419:in `run_test_suites' /usr/local/lib/ruby/gems/1.8/gems/minitest-1.5.0/lib/minitest/unit.rb:393:in `run' /usr/local/lib/ruby/gems/1.8/gems/minitest-1.5.0/lib/minitest/unit.rb:334:in `autorun' See http://ci.pivotallabs.com:3333/builds/RubyGemsGitHub/5a478ecdf462be68f7872ef1d7ac2f183e84ffbd for details. From transfire at gmail.com Sat Dec 11 16:07:05 2010 From: transfire at gmail.com (Trans) Date: Sat, 11 Dec 2010 13:07:05 -0800 (PST) Subject: [Rubygems-developers] Contributing to Ruby Projects In-Reply-To: References: Message-ID: <4882d3e4-0c5a-4c4d-8b15-bfd711dfb3f9@f21g2000prn.googlegroups.com> First let me thank everyone who responded. Some of the comments were very helpful and I will take stock of them in the future. I may yet respond to some of them, but I would like to respond to Eric now, since he took the time to make a point by point reanalysis of our conversations. Just to clear, my overall issues with this have more to do with Ryan than anyone else. I think thats obvious, but I do still think there were some discouraging factors with some of the other conversations too. On Dec 10, 1:55 am, Eric Hodel wrote: > On Dec 8, 2010, at 15:12, Trans wrote: > > > I would like some constructive appraisal. I recently offered some > > patches to RubyGems. I feel I was making my best effort to contribute > > some functionality to the code base that would be useful to > > developers. But in this process, rather then feel a part of a > > community effort, even if only a minor part, I felt rather skewered? > > To begin with I would like to point out that you have deleted several of your comments forcing me to respond from memory and leaving their contents at the risk of "he-said, she-said". I did. I actually attempted to delete the all the commits altogether, but it turns out that is not possible. It gets to a point were I would rather delete them and forget the whole affair. > I have reordered these pull requests chronologically. > > > https://github.com/rubygems/rubygems/pull/8 > > I'm not sure what your complaint is here. The request is reasonable but you have not acted on it. > > It is your job to make your pull requests acceptable for contribution. That request came only after I may a snarky remark about no one commenting on the patch. From my perspective it appeared that when I did something acceptable, it was being ignored. When I did something that wasn't it was an opportunity to "attack" (of course that perception almost entirely has to do with Ryan). > > https://github.com/rubygems/rubygems/pull/12 > > Since you have deleted your comment stream I'll have to reconstruct your counter-arguments from memory. I have them out of order because this email is already up to 5K of text and I don't think it's worth my time to order them properly. > I rejected plain-YAML gemspecs because it is not a type-safe data format, and that it increases maintenance burden of future RubyGems versions for the benefit of a small minority of users. I don't see anything unfair about this assessment. And I explained that it is as type-safe b/c the format is parsed by the code. Putting a type `!` line in the YAML doesn't make an iota of difference. But you never explained to me how it would. Of course there is always maintenance, but in the scheme of things, this one is pretty small. What was it about 20-30 lines of code? > I asked if there were any non-ruby tools that used a YAML gemspec. If such a tool existed it might be a reason to consider this feature. > > You did not name any non-ruby tools that used a YAML gemspec, but you came up with some hypothetical ruby tools that could use this feature. You claimed that this feature was important because either RubyGems consumed too many resources or that it would not be available. You are asking for something that can't exist b/c there is no such thing as a plain YAML gemspec. I was trying to create such a thing so such tools could exist. I gave you three use cases, two where it could be helpful if loading Rubygems were unnecessary (a web search app gathering info about projects and a web-app to edit the YAML gemspec), and a case where it can't be loaded (Setup.rb is an alternative installer, it does not make any sense for it to load rubygems, but it could utilize a pure YAML gemspec). > In brief, I responded that if it's a ruby tool it can use RubyGems and that RubyGems resource burden is not too large. As of Ruby 1.9 RubyGems is always available. (Adding a feature to RubyGems specifically for Ruby 1.8 requires an overwhelming need.) I believe this is where I closed the ticket as you could not come up with a satisfactory reason for including plain-YAML gemspecs. The thing is that you dismissed those use cases so quickly and so summarily, that it seemed to me that you weren't really giving it that much thought. I also made it very clear that good bit of the motivation for this patch came from the fact that the Bundler folks have been pushing people to move to hand-edited gemspecs. I was actually surprised to learn that I was mistaken in thinking that was also the stance of the Rubygems team. > You persisted, however and I continued to respond. > You argued that it could be made "safer" and I referenced the past history of junk data in gemspecs and Jeremy Hindegardener's talk at RubyConf 2010 as a demonstration that it probably can't be made safer. Actually, I argued that it wasn't any less safe then it was already. I only made a passing parenthetical comment that if type safety is a concern that improvement could be made --but that applied to the current design in general, not this particular feature. > You said it would be "more convenient" and I responded that I could not find a gem that used YAML in its .gemspec file in a few minutes of searching. I pointed out that the community has decided that the de-facto format for gemspec files is Ruby. > > I thought you would take my lack of discovery of YAML .gemspec files as an opportunity to show me a single project that used YAML in its gemspecs. This would demonstrate there was even a handful of RubyGems users who would benefit from this feature but you did not (or could not?). Again, I did show you and you simply dismissed those cases as people "refusing to conform to best practices". Ore was the most obvious example --it was so important for that developer that they went out of their way to create a whole project devoted to doing it. > You pointed out ore which uses plain-YAML to create gemspecs and gems and used it as an argument in your favor. > > I responded that if ore supports this you should use ore as it does what you want already and requires no changes to RubyGems. Since you did not demonstrate that there was another RubyGems user who desires plain-YAML gemspecs I responded that there is only one person that wants this feature and that was not enough users to include it. I reiterated that the community has decided they prefer ruby. > If you look at the download counts, people overwhelmingly prefer to use ruby to build gems. Hoe has 690,000 and Jeweler has 56,000. Ore has 453. This is unreasonable argument. I can't provide examples of something that CAN'T exist. Both Ore and my own tools took many man-hours to make it possible --so that's not something one can reasonably expect of the common community. Clearly most people are not going to do that. The community is not getting much of an option. Ore is brand new. So it's not really a fair indication. > You claimed that I did not understand the intent of your feature, but I was perfectly clear on that as both your initial description and the content of your patch were perfectly clear. No. I only clarified my argument b/c some of your statements indicated that you may not have understood a particular aspect of the intent. I was not saying "you did not", but "if you you did not". > For a feature to be added to RubyGems one of the requirements is that it cannot be implemented outside RubyGems. Ore shows that it is possible to implement this feature outside of RubyGems. That's a fair argument. And I can accept that. That's not to say their aren't disadvantages to the lack of mainstream support, but its enough. And thanks to Gems plugin support it is very doable. > I now have a full page and over 1.5k of summary in this email of our conversation past the point where I closed the issue. We had a long and thorough discussion of the issue but you could not bring up any reason for inclusion of plain-YAML gemspecs. I believe that my conduct in our conversation was fair and reasonable and that any unbiased reader would find it so. I mostly agree. My only complaint with our conversation is what I mentioned above. You seemed very short with me, as if you were annoyed to have to discuss this, along with a rush to judgment --actually more than that, the judgment seemed predetermined, so your end of conversation always seemed stilted --it didn't feel like an earnest conversation/debate. > Again, your request for plain-YAML gemspecs is not suitable for inclusion in RubyGems Well, if you want to reiterate... > It is not type-safe. I don't see how that is true. > It benefits a single user. Not a fair assessment. > It is adequately covered by functionality outside of RubyGems Okay. > It increases the maintenance burden of RubyGems. It's small. But at this point it doesn't matter any way ;-) > If it were Dave Thomas, Chad Fowler, Jim Weirich or anyone else who had suggested this feature I would reject it for exactly these reasons as well. I am not saying you would not. I had no problem with your assessments. However I suspect you would have discussed the topic with them in a more open-minded manner. > > https://github.com/rubygems/rubygems/pull/14 > > I gave you a frank assessment, approving your idea but rejecting your implementation, specifically of Gem::Resource. I recommended a Hash instead as it avoids the high run-time cost (which must be paid every time an installed gem is activated): > > > It appears that a resources Hash on Gem::Specification would be a better solution. This implementation requires triple-dispatch. (Gem::Specification#add_resource => Gem::Resource#add_resource => #resource_name => Hash#[]= vs Gem::Specification#add_resource => Hash#[]=) > > You refused to budge on Gem::Resource saying the aliases were provided for convenience. I didn't refuse. I was discussing it. This is what I mean about a rush to judgment. > You said your patch was not 100% complete. > I rejected aliases again, I explained how to perform a feature-check for #add_resource (which is currently implemented for several things in #to_ruby) and pointed out that your tests do not require what you claimed to. I asked why you created a pull request if your code wasn't ready for commit. > > If you wish to have your idea reviewed you should come here to the mailing list. If you wish to have your incomplete implementation reviewed you should come here to the mailing list. Yes. And for the record that was partly b/c I was already tired from the previous discussion. I wasn't even sure I'd bother with it at all at that point. But I decided to go ahead and test the water with what I had so far. I specifically did not expect the push to be accepted AS IS, only to get the ball rolling and get feedback. I admitted that I prematurely pushed the commit. So what was the point of berating me for obviously unfinished things, like an empty comment or a TODO (clearly commented) to add URL validation? > You also continued to claim that Gem::Resource#hash and #eql? were required despite my statement that I had applied your patch, deleted these methods and had a successful run. > > In all, despite rejecting aliases and the implementation that required them you continued to fight for them, refusing to come to any compromise. What? You are confused. I gave an example of a failing test when I deleted the #hash method. All you said was "there must be some other bug". Well that was less than two days ago. How fast do you think I work? When did I have time to "compromise"? > Now that I have reviewed this again I have another reason to reject your implementation, the Ruby gemspec is run at gem load time and the creation of a new object and multiple-dispatch to set fields in it will be too slow in comparison to a simple hash. Honestly, I could care less about the exact implementation. I just wanted to discuss the features I was attempting to address with it. It may be possible to address those with a different implementation. Again why is there such a rush? The aliases were for convenience of short forms. I know you don't take much stock in it, but the idea was simply to make specifying these resource very easy. E.g. It might look like: resources :mail => ..., :chat => ..., :docs => ... Rather then the less orderly resources :mailing_list => '...', :chatroom => '...', :documentation => '...' The sort forms are much easier to remember. So I don't so much care about having many various aliases, but I do care about the short forms. Clarifying that, I was hoping a compromise could be found. But you up and closed the ticket before I have time to relay that (and Ryan had further killed my desire to even try any more). The other issue was arbitrary entries. Ryan seems to be against those (though it's hard to tell b/c he wouldn't actually say what his problem was half the time, only that my code was "wrong".) A hash would allow that, but if that's not desirable either, then you may as well simply add a entry to the gemspec for each url, akin to homepage. e.g. maling_list '...; chatroom '...' documentation '...' Personally, I think the lack of ability to add arbitrary entries would be regrettable. > As I stated, your idea is great and had been discussed prior to submitted your pull request. > > Your implementation of Gem::Resource is rejected. It is too slow compared to a Hash and does not provide enough benefit. > > Gem::Specification#add_resource is great and fits well with existing Gem::Specification methods. > > At this point it's hard for me to determine what you are expecting. Is it clearer now? > > I'm not sure why anyone would contribute to a Ruby project if it transpires like this. But then maybe thats the way it is? > > As I said in pull request 12: > > RubyGems is a core component of the ruby community. Due to its core position it needs to have a conservative policy towards improvements and those improvements that are accepted need to have simple, concise and easy to maintain implementations. > > It is unreasonable to expect an admittedly incomplete patch would be accepted immediately. I never expected that, and this topic has nothing to do with that. > It is unreasonable to believe that an patch submitted to RubyGems would not undergo a thorough and critical review. Indeed! "thorough" and "critical", not "summarily" and "disrespectful". > When given a review it is your obligation to come to a compromise but you refuse to budge. You claim you were not given enough time to budge, but you were amply active in replying to my commentary for the past two days, and I have spent 10s of kilobytes and hours of time attempting to explain why your patches were rejected and what would make them acceptable. > I will now respond to the remainder of the last comment on pull request 12: > > https://github.com/rubygems/rubygems/pull/12#issuecomment-601579 > > > What do you mean I didn't budge? I was trying to discuss the issue, and you all get in a dither over it. (I mean really, consider one of the first things you did was make a sharply worded remark about not changing style because I dropped a then from an if. Which I later discover, btw, isn't a RubyGems code style at all b/c then isn't used in many places. > > It is not worth our time to update the style on every file. If you check the history you will see that older RubyGems codes does not use then. It is required now. I believe there is another pull request mentioning this but it has been over three hours since I started writing this email now and I am can't be bothered to find it. > > > And don't even get me started on Ryan. That asshole spends his time cursing at me on every other line for anything at all, like using inject (heaven forbid!) or putting a blank comment line which I use as a device as a reminder to go back and write docs. It's absolutely ridiculous. And unworthy of an important project like Rubygems. > > Ryan may have been harsh in his critique of your code, but I don't recall he gave you any less critique than he did for the students he taught at the UW extension course. Does he say "fuck" all the time to them? > I don't recall that Ryan has ever called you an asshole. I'm know you are aware that Ryan and I work together on a daily basis, and I am certain that you have formed opinions of Ryan's opinion of you. I will clarify that this includes any private conversations we have had. > > (Knowing Ryan as we both do, however, this will change tomorrow when we meet.) > > > The fact is I was only ever providing my take on the matter, why I was seeking to do it that way, I worked on it as part of what I'd like to see in RubyGems. I don't work for you. You are not my employer. I submitted patches that were geared toward use cases that I would make of RubyGems. Why would I do anything else? > > I don't doubt the sincerity of your commits. I gave what I felt was a fair consideration of your ideas and responded appropriately. > > > Right or wrong, you guys didn't even allow for appropriate time to "budge". > > I consider two days of response on pull request 12 to be adequate time. I consider your frequent responses on pull request 14 to be adequate time. > > > All you and Ryan wanted to do was for me to say "yes sir, sorry sir! Hop to, sir. I'll have those "fixes" to you by morning". > > I don't care how long you take. If you wish to stop and think about something then go ahead. Ha Ha. That's rich. Does that just prove your expectation? > I'm not sure what you wish to imply with your quotes around "fixes". > > Perhaps you mean my reasoning was illogical, but I believe I gave you logical reasons for rejection. > > Perhaps you are mocking me, I find that amusing. > > Perhaps you just don't understand that your code was not acceptable despite me going to great pains to explain how and why it was not. But what about the purpose of a conversation? Is this a one way street where you tell me what you don't want and I run off and code for you? Is it not important to converse and come to a conclusion? I am not unreasonable. I may be somewhat suborn, but I do relent to logic. But I expect an openness to possibilities in discussion. That's what I mean by a project I don't want to contribute to. > > We'll forget it. You all can enjoy YOUR "open source" project. I do not "contribute to open source" project run by assholes. > > And now you have insulted me. My apologies. I shouldn't not have used that term but at the time I felt a need to be a more forceful than saying literally "inconsiderate and rude". (And again I emphasis that almost entirely applies to Ryan). > > And honestly I am sorry if I am putting more of this on you right now then you probably deserve. Ryan really is ten times worse. None the less this has been a wholly frustrating experience. And I can only think that ultimately these kinds of things will be very bad for Ruby in general. > > You are putting more of this on me than I deserve, and it's unfair. > > I've spent hours of my time trying to show you what was unacceptable in your patches and you have refused to acknowledge a single point. That's what is unfair to me. How can two days be enough time to discuss something when this is only a part time, volunteer activity? What about other people getting in on the conversation? My RDoc patch sat there 5 days and no one said word one. Why wasn't two days enough there? I'll just reiterate my point from before, two days seems fair to you, b/c you already decided. "tough shit" is how you put it on another topic. There was little intent of real discussion. You have also made it clear that you were focusing more on the implementation then the design goals. I was still trying to assess exactly what would and would not be acceptable. B/c of this you have wholly mistaken my further discussion as a "refusal to acknowledge". Don't you see how that indicates the "yes sire!" attitude that I felt? > Now you're sending an email to the list to garner sympathy. I've now spent nearly four hours writing this response. You think you're frustrated? Actually I earnestly wanted to see how much my perception was being blurred by my interaction with Ryan. As I said this has 10 times more to do with my interaction with him then with you. I also wanted others to see how Ryan behaves b/c I don't know how else to try to effect Ryan. I think others need to be aware of it b/c it is effects the development of a project. > > Go ahead and blame we all you want. I don't calm to be wholly innocent. But I do know that all I did was earnestly try to contribute to the improvement of Gems and was essentially eviscerated for my troubles. > > No, you did not try to earnestly contribute. As soon as you sensed the slightest bit of resistance you immediately became defensive. You refused to budge on anything. This is not how you behave if you want to contribute. Well, I tried to defend my design "hopes" for the project, if you will. I don't think defending ones ideas should be considered "defensive" in the sense that it was wrong of me to do so. Why wouldn't you expect me to defend them? > I did not eviscerate you, I gave your patches and ideas a critical review. It seems that you do not understand what a critical review is. You may not like it. I have gone through many and I did not like them either, but they have helped me become a better programmer. > > > Is this really what one should expect? > > It appears you have decided my rejection of 12 and 14 was because I have some personal vendetta against you. I believe I gave your ideas a fair consideration and commented on them accordingly. You completely misunderstood then. I have no indication that you would do such a thing (with the possible exception of your association with Ryan. Though I actually did not know you worked with him daily). I do not get any indication from your comments that anything like that is going on. But I believe I have explained my perceptions above. (Of course, Ryan is a different story. I know that he purposefully attacks me and has proven his vindictive nature time and again.) > Not every change submitted can be included in RubyGems. > > In one of your comments on pull request 12 you said something like: > > > Necessity is the mother of invention, but everyone who has used a remote control knows that convenience is where it's at. > > To which I responded: > > > PS: Restrict yourself to technical merits and avoid editorializing. The pull request comments are here for the discussion of utility, usability and maintainability of proposed changes. They are not to make undecipherable editorial comments centered on necessity, invention and remote controls. > It appears you don't actually want to have a discussion on the grounds of utility, usability or maintainability but instead you wish to be right and you wish to get your way. Whenever I would counter one of your arguments you would shift to a new different argument. When I exhausted all those you claimed I didn't understand you despite understanding you perfectly clearly. > > Finally you attempt to appeal to this list to garner sympathy. > > Your evasive behavior and martyrdom are exceptionally frustrating. > > Despite the deletion of the majority of your commentary in the pull requests which should reasonably explain the reasons for my frustration, I am again going to say that when you don't get your way you present yourself as a martyr and throw a fit as you have done in this instance. > > Throwing a fit when you don't get your way is a behavior most people have grown out of by the time they're 10. You're three times that age now. Yes and no. I found it so frustrating dealing with Ryan, that at one point I just said "hell with it". It was late, I was tired, and I just wanted to forget about it at that point, and so attempted to just delete it all and walk away. That didn't work of course. This post was not about throwing a fit though. It was about respect. Not just what others were giving (or not) to me, but I to them. I felt the conversations had gotten away from were they should be and putting it out for others would help bring perspective. Again this had vastly more to do with Ryan then you. > I tried to give you the benefit of the doubt when you submitted your pull requests. I hope that my comments here and on the pull requests adequately show that to the other readers of this email and this list. > > You've reacted exactly this way before and, unfortunately, you will probably continue to do so. Based on your behavior I'm not certain I wish to continue to review your contributions without rejecting them outright. > > It certainly isn't worth my time as I've lost an entire day of productive work dealing with your attempt at martyrdom (four hours on this email alone). I can only hope that you will actually stop contributing. Well, I actually appreciate you taking the time. I hope my reply offers some clarity about our different perspectives. > Sincerely, > > Eric Hodel > The "asshole" > > PS: I'm not going to respond to any of your further emails on this thread, so feel free to call me whatever additional names you like! I understand of course. It's the same way that I would just like to delete all the commits, forget about it and and move on. You don't need to reply. I think it's been flushed out enough and we can just take our respective lessons from it as we see fit. From ryand-ruby at zenspider.com Sat Dec 11 17:41:42 2010 From: ryand-ruby at zenspider.com (Ryan Davis) Date: Sat, 11 Dec 2010 14:41:42 -0800 Subject: [Rubygems-developers] Contributing to Ruby Projects In-Reply-To: <4882d3e4-0c5a-4c4d-8b15-bfd711dfb3f9@f21g2000prn.googlegroups.com> References: <4882d3e4-0c5a-4c4d-8b15-bfd711dfb3f9@f21g2000prn.googlegroups.com> Message-ID: <0CA2C00D-5EAD-4503-A49B-71FAFA0AAFD9@zenspider.com> On Dec 11, 2010, at 13:07 , Trans wrote: > "tough shit" is how you put it on another topic. erikh (erik hollensbe) != drbrain (eric hodel) From devnull+rubygems-ci at pivotallabs.com Sun Dec 12 08:01:05 2010 From: devnull+rubygems-ci at pivotallabs.com (devnull+rubygems-ci at pivotallabs.com) Date: Sun, 12 Dec 2010 13:01:05 +0000 Subject: [Rubygems-developers] [CruiseControl] RubyGemsGitHub build 1e71d86 failed Message-ID: <4d04c791684d9_7270..fdbe313802885@ci.pivotallabs.com.tmail> The build failed. CHANGES ------- Revision ...1e71d86bbdb22c850fc6aab60b04b602faf2a00a committed by Ryan Davis on 2010-12-12 12:55:02 + Added fuzzy name matching on install failures. (gstark/presidentbeef) lib/rubygems/command.rb | 12 ++++++++- lib/rubygems/commands/fetch_command.rb | 2 +- lib/rubygems/commands/install_command.rb | 2 +- lib/rubygems/spec_fetcher.rb | 31 +++++++++++++++++++++++++ lib/rubygems/text.rb | 35 +++++++++++++++++++++++++++++ test/test_gem_commands_install_command.rb | 23 +++++++++++++++++++ test/test_gem_text.rb | 21 +++++++++++++++++ 7 files changed, 122 insertions(+), 4 deletions(-) Revision ...d8e8803ee0072a538fdcaec59240e83531d2cd46 committed by Ryan Davis on 2010-12-12 12:53:26 minor cleanup .autotest | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) Revision ...98ae41e2b1499ee8b84d7b76265811f613430b15 committed by Ryan Davis on 2010-12-12 11:12:39 Added tests for Gem::Text.format test/test_gem_text.rb | 22 ++++++++++++++++++++++ 1 files changed, 22 insertions(+), 0 deletions(-) Revision ...687220fb6f1f8ccf36a6884b8e7761445ead3be4 committed by Ryan Davis on 2010-12-12 10:37:25 Possibly overzealous removal of rubyforge & svn oriented rake tasks to get tests running after my hoe update Rakefile | 52 +--------------------------------------------------- 1 files changed, 1 insertions(+), 51 deletions(-) TEST FAILURES AND ERRORS ----------------------- Name: test_execute_nonexistent_with_hint(TestGemCommandsInstallCommand) Type: Failure Message: [Gem::SystemExitException] exception expected, not Class: Message: <"wrong number of arguments (1 for 0)"> ---Backtrace--- /home/pivotal/.cruise/projects/RubyGemsGitHub/work/test/../lib/rubygems/spec_fetcher.rb:196:in `flatten' /home/pivotal/.cruise/projects/RubyGemsGitHub/work/test/../lib/rubygems/spec_fetcher.rb:196:in `suggest_gems_from_name' ./lib/rubygems/command.rb:160:in `show_lookup_failure' /home/pivotal/.cruise/projects/RubyGemsGitHub/work/test/../lib/rubygems/commands/install_command.rb:131:in `execute' /home/pivotal/.cruise/projects/RubyGemsGitHub/work/test/../lib/rubygems/commands/install_command.rb:115:in `each' /home/pivotal/.cruise/projects/RubyGemsGitHub/work/test/../lib/rubygems/commands/install_command.rb:115:in `execute' ./test/test_gem_commands_install_command.rb:186:in `test_execute_nonexistent_with_hint' /usr/local/lib/ruby/gems/1.8/gems/minitest-1.5.0/lib/minitest/unit.rb:136:in `assert_raises' ./test/test_gem_commands_install_command.rb:185:in `test_execute_nonexistent_with_hint' ./lib/rubygems/user_interaction.rb:40:in `use_ui' ./lib/rubygems/user_interaction.rb:63:in `use_ui' ./test/test_gem_commands_install_command.rb:184:in `test_execute_nonexistent_with_hint' /usr/local/lib/ruby/gems/1.8/gems/minitest-1.5.0/lib/minitest/unit.rb:458:in `__send__' /usr/local/lib/ruby/gems/1.8/gems/minitest-1.5.0/lib/minitest/unit.rb:458:in `run' /usr/local/lib/ruby/gems/1.8/gems/minitest-1.5.0/lib/minitest/unit.rb:426:in `run_test_suites' /usr/local/lib/ruby/gems/1.8/gems/minitest-1.5.0/lib/minitest/unit.rb:420:in `each' /usr/local/lib/ruby/gems/1.8/gems/minitest-1.5.0/lib/minitest/unit.rb:420:in `run_test_suites' /usr/local/lib/ruby/gems/1.8/gems/minitest-1.5.0/lib/minitest/unit.rb:419:in `each' /usr/local/lib/ruby/gems/1.8/gems/minitest-1.5.0/lib/minitest/unit.rb:419:in `run_test_suites' /usr/local/lib/ruby/gems/1.8/gems/minitest-1.5.0/lib/minitest/unit.rb:393:in `run' /usr/local/lib/ruby/gems/1.8/gems/minitest-1.5.0/lib/minitest/unit.rb:334:in `autorun' --------------- ./test/test_gem_commands_install_command.rb:185 Name: test_execute_nonexistent(TestGemCommandsInstallCommand) Type: Failure Message: [Gem::SystemExitException] exception expected, not Class: Message: <"wrong number of arguments (1 for 0)"> ---Backtrace--- /home/pivotal/.cruise/projects/RubyGemsGitHub/work/test/../lib/rubygems/spec_fetcher.rb:196:in `flatten' /home/pivotal/.cruise/projects/RubyGemsGitHub/work/test/../lib/rubygems/spec_fetcher.rb:196:in `suggest_gems_from_name' ./lib/rubygems/command.rb:160:in `show_lookup_failure' /home/pivotal/.cruise/projects/RubyGemsGitHub/work/test/../lib/rubygems/commands/install_command.rb:131:in `execute' /home/pivotal/.cruise/projects/RubyGemsGitHub/work/test/../lib/rubygems/commands/install_command.rb:115:in `each' /home/pivotal/.cruise/projects/RubyGemsGitHub/work/test/../lib/rubygems/commands/install_command.rb:115:in `execute' ./test/test_gem_commands_install_command.rb:167:in `test_execute_nonexistent' /usr/local/lib/ruby/gems/1.8/gems/minitest-1.5.0/lib/minitest/unit.rb:136:in `assert_raises' ./test/test_gem_commands_install_command.rb:166:in `test_execute_nonexistent' ./lib/rubygems/user_interaction.rb:40:in `use_ui' ./lib/rubygems/user_interaction.rb:63:in `use_ui' ./test/test_gem_commands_install_command.rb:165:in `test_execute_nonexistent' /usr/local/lib/ruby/gems/1.8/gems/minitest-1.5.0/lib/minitest/unit.rb:458:in `__send__' /usr/local/lib/ruby/gems/1.8/gems/minitest-1.5.0/lib/minitest/unit.rb:458:in `run' /usr/local/lib/ruby/gems/1.8/gems/minitest-1.5.0/lib/minitest/unit.rb:426:in `run_test_suites' /usr/local/lib/ruby/gems/1.8/gems/minitest-1.5.0/lib/minitest/unit.rb:420:in `each' /usr/local/lib/ruby/gems/1.8/gems/minitest-1.5.0/lib/minitest/unit.rb:420:in `run_test_suites' /usr/local/lib/ruby/gems/1.8/gems/minitest-1.5.0/lib/minitest/unit.rb:419:in `each' /usr/local/lib/ruby/gems/1.8/gems/minitest-1.5.0/lib/minitest/unit.rb:419:in `run_test_suites' /usr/local/lib/ruby/gems/1.8/gems/minitest-1.5.0/lib/minitest/unit.rb:393:in `run' /usr/local/lib/ruby/gems/1.8/gems/minitest-1.5.0/lib/minitest/unit.rb:334:in `autorun' --------------- ./test/test_gem_commands_install_command.rb:166 Name: test_active_count(TestGemDependencyList) Type: Error Message: NoMethodError: undefined method `count' for []:Array /home/pivotal/.cruise/projects/RubyGemsGitHub/work/test/../lib/rubygems/dependency_list.rb:205:in `active_count' ./test/test_gem_dependency_list.rb:37:in `send' ./test/test_gem_dependency_list.rb:37:in `test_active_count' /usr/local/lib/ruby/gems/1.8/gems/minitest-1.5.0/lib/minitest/unit.rb:458:in `__send__' /usr/local/lib/ruby/gems/1.8/gems/minitest-1.5.0/lib/minitest/unit.rb:458:in `run' /usr/local/lib/ruby/gems/1.8/gems/minitest-1.5.0/lib/minitest/unit.rb:426:in `run_test_suites' /usr/local/lib/ruby/gems/1.8/gems/minitest-1.5.0/lib/minitest/unit.rb:420:in `each' /usr/local/lib/ruby/gems/1.8/gems/minitest-1.5.0/lib/minitest/unit.rb:420:in `run_test_suites' /usr/local/lib/ruby/gems/1.8/gems/minitest-1.5.0/lib/minitest/unit.rb:419:in `each' /usr/local/lib/ruby/gems/1.8/gems/minitest-1.5.0/lib/minitest/unit.rb:419:in `run_test_suites' /usr/local/lib/ruby/gems/1.8/gems/minitest-1.5.0/lib/minitest/unit.rb:393:in `run' /usr/local/lib/ruby/gems/1.8/gems/minitest-1.5.0/lib/minitest/unit.rb:334:in `autorun' See http://ci.pivotallabs.com:3333/builds/RubyGemsGitHub/1e71d86bbdb22c850fc6aab60b04b602faf2a00a for details. From thewoolleyman at gmail.com Sun Dec 12 15:05:52 2010 From: thewoolleyman at gmail.com (Chad Woolley) Date: Sun, 12 Dec 2010 13:05:52 -0700 Subject: [Rubygems-developers] [CruiseControl] RubyGemsGitHub build 1e71d86 failed In-Reply-To: <4d04c791684d9_7270..fdbe313802885@ci.pivotallabs.com.tmail> References: <4d04c791684d9_7270..fdbe313802885@ci.pivotallabs.com.tmail> Message-ID: On Sun, Dec 12, 2010 at 6:01 AM, wrote: > The build failed. > > CHANGES > ------- > Revision ...1e71d86bbdb22c850fc6aab60b04b602faf2a00a committed by Ryan Davis on 2010-12-12 12:55:02 http://c2.com/cgi/wiki?FixBrokenWindows From ryand-ruby at zenspider.com Sun Dec 12 19:20:58 2010 From: ryand-ruby at zenspider.com (Ryan Davis) Date: Sun, 12 Dec 2010 16:20:58 -0800 Subject: [Rubygems-developers] [CruiseControl] RubyGemsGitHub build 1e71d86 failed In-Reply-To: References: <4d04c791684d9_7270..fdbe313802885@ci.pivotallabs.com.tmail> Message-ID: <7E245385-6B08-4B46-BCBB-D3479ADD5DDF@zenspider.com> On Dec 12, 2010, at 12:05 , Chad Woolley wrote: > On Sun, Dec 12, 2010 at 6:01 AM, wrote: >> The build failed. >> >> CHANGES >> ------- >> Revision ...1e71d86bbdb22c850fc6aab60b04b602faf2a00a committed by Ryan Davis on 2010-12-12 12:55:02 > > http://c2.com/cgi/wiki?FixBrokenWindows Was that necessary? Do you feel better? From ryand-ruby at zenspider.com Sun Dec 12 19:26:58 2010 From: ryand-ruby at zenspider.com (Ryan Davis) Date: Sun, 12 Dec 2010 16:26:58 -0800 Subject: [Rubygems-developers] [CruiseControl] RubyGemsGitHub build 1e71d86 failed In-Reply-To: <4d04c791684d9_7270..fdbe313802885@ci.pivotallabs.com.tmail> References: <4d04c791684d9_7270..fdbe313802885@ci.pivotallabs.com.tmail> Message-ID: <4536CD13-2EAC-4BA1-87BF-B43C72BC0D02@zenspider.com> On Dec 12, 2010, at 05:01 , devnull+rubygems-ci at pivotallabs.com wrote: > Name: test_execute_nonexistent_with_hint(TestGemCommandsInstallCommand) > Type: Failure > Message: [Gem::SystemExitException] exception expected, not > Class: > Message: <"wrong number of arguments (1 for 0)"> > ---Backtrace--- > /home/pivotal/.cruise/projects/RubyGemsGitHub/work/test/../lib/rubygems/spec_fetcher.rb:196:in `flatten' This is 1.8.6, isn't it? If so, then this CI should be shut down / changed to 1.8.7. From thewoolleyman at gmail.com Mon Dec 13 02:02:06 2010 From: thewoolleyman at gmail.com (Chad Woolley) Date: Mon, 13 Dec 2010 00:02:06 -0700 Subject: [Rubygems-developers] [CruiseControl] RubyGemsGitHub build 1e71d86 failed In-Reply-To: <7E245385-6B08-4B46-BCBB-D3479ADD5DDF@zenspider.com> References: <4d04c791684d9_7270..fdbe313802885@ci.pivotallabs.com.tmail> <7E245385-6B08-4B46-BCBB-D3479ADD5DDF@zenspider.com> Message-ID: On Sun, Dec 12, 2010 at 5:20 PM, Ryan Davis wrote: > > On Dec 12, 2010, at 12:05 , Chad Woolley wrote: > >> On Sun, Dec 12, 2010 at 6:01 AM, ? wrote: >>> The build failed. >>> >>> CHANGES >>> ------- >>> Revision ...1e71d86bbdb22c850fc6aab60b04b602faf2a00a committed by Ryan Davis on 2010-12-12 12:55:02 >> >> http://c2.com/cgi/wiki?FixBrokenWindows > > Was that necessary? Do you feel better? Yes, because there were repeated checkins to a red build. That is bad. I ignored the first couple. From thewoolleyman at gmail.com Mon Dec 13 02:05:37 2010 From: thewoolleyman at gmail.com (Chad Woolley) Date: Mon, 13 Dec 2010 00:05:37 -0700 Subject: [Rubygems-developers] [CruiseControl] RubyGemsGitHub build 1e71d86 failed In-Reply-To: <4536CD13-2EAC-4BA1-87BF-B43C72BC0D02@zenspider.com> References: <4d04c791684d9_7270..fdbe313802885@ci.pivotallabs.com.tmail> <4536CD13-2EAC-4BA1-87BF-B43C72BC0D02@zenspider.com> Message-ID: On Sun, Dec 12, 2010 at 5:26 PM, Ryan Davis wrote: > > On Dec 12, 2010, at 05:01 , devnull+rubygems-ci at pivotallabs.com wrote: > >> Name: test_execute_nonexistent_with_hint(TestGemCommandsInstallCommand) >> Type: Failure >> Message: [Gem::SystemExitException] exception expected, not >> Class: >> Message: <"wrong number of arguments (1 for 0)"> >> ---Backtrace--- >> /home/pivotal/.cruise/projects/RubyGemsGitHub/work/test/../lib/rubygems/spec_fetcher.rb:196:in `flatten' > > This is 1.8.6, isn't it? > > If so, then this CI should be shut down / changed to 1.8.7. This is the first time someone has asked for it to be changed. 1.8.6 is just the system ruby on this CI box, but I'm glad to hook it up with RVM for any interpreters we wish. Let me know which ones you want. -- Chad From drbrain at segment7.net Mon Dec 13 02:58:40 2010 From: drbrain at segment7.net (Eric Hodel) Date: Sun, 12 Dec 2010 23:58:40 -0800 Subject: [Rubygems-developers] [CruiseControl] RubyGemsGitHub build 1e71d86 failed In-Reply-To: References: <4d04c791684d9_7270..fdbe313802885@ci.pivotallabs.com.tmail> <4536CD13-2EAC-4BA1-87BF-B43C72BC0D02@zenspider.com> Message-ID: On Dec 12, 2010, at 23:05, Chad Woolley wrote: > On Sun, Dec 12, 2010 at 5:26 PM, Ryan Davis wrote: >> >> On Dec 12, 2010, at 05:01 , devnull+rubygems-ci at pivotallabs.com wrote: >> >>> Name: test_execute_nonexistent_with_hint(TestGemCommandsInstallCommand) >>> Type: Failure >>> Message: [Gem::SystemExitException] exception expected, not >>> Class: >>> Message: <"wrong number of arguments (1 for 0)"> >>> ---Backtrace--- >>> /home/pivotal/.cruise/projects/RubyGemsGitHub/work/test/../lib/rubygems/spec_fetcher.rb:196:in `flatten' >> >> This is 1.8.6, isn't it? >> >> If so, then this CI should be shut down / changed to 1.8.7. > > This is the first time someone has asked for it to be changed. 1.8.6 > is just the system ruby on this CI box, but I'm glad to hook it up > with RVM for any interpreters we wish. Let me know which ones you > want. Supported platforms are 1.8.7, 1.9.1, 1.9.2 From thewoolleyman at gmail.com Mon Dec 13 03:46:44 2010 From: thewoolleyman at gmail.com (Chad Woolley) Date: Mon, 13 Dec 2010 01:46:44 -0700 Subject: [Rubygems-developers] [CruiseControl] RubyGemsGitHub build 1e71d86 failed In-Reply-To: References: <4d04c791684d9_7270..fdbe313802885@ci.pivotallabs.com.tmail> <4536CD13-2EAC-4BA1-87BF-B43C72BC0D02@zenspider.com> Message-ID: On Mon, Dec 13, 2010 at 12:58 AM, Eric Hodel wrote: > On Dec 12, 2010, at 23:05, Chad Woolley wrote: >> On Sun, Dec 12, 2010 at 5:26 PM, Ryan Davis wrote: >>> >>> On Dec 12, 2010, at 05:01 , devnull+rubygems-ci at pivotallabs.com wrote: >>> >>>> Name: test_execute_nonexistent_with_hint(TestGemCommandsInstallCommand) >>>> Type: Failure >>>> Message: [Gem::SystemExitException] exception expected, not >>>> Class: >>>> Message: <"wrong number of arguments (1 for 0)"> >>>> ---Backtrace--- >>>> /home/pivotal/.cruise/projects/RubyGemsGitHub/work/test/../lib/rubygems/spec_fetcher.rb:196:in `flatten' >>> >>> This is 1.8.6, isn't it? >>> >>> If so, then this CI should be shut down / changed to 1.8.7. >> >> This is the first time someone has asked for it to be changed. ?1.8.6 >> is just the system ruby on this CI box, but I'm glad to hook it up >> with RVM for any interpreters we wish. ?Let me know which ones you >> want. > > Supported platforms are 1.8.7, 1.9.1, 1.9.2 Ok. If I set them up, are committers going to keep them green, or question their necessity? If not, I've got better things to spend my time on... From thewoolleyman at gmail.com Mon Dec 13 03:50:55 2010 From: thewoolleyman at gmail.com (Chad Woolley) Date: Mon, 13 Dec 2010 01:50:55 -0700 Subject: [Rubygems-developers] [CruiseControl] RubyGemsGitHub build 1e71d86 failed In-Reply-To: References: <4d04c791684d9_7270..fdbe313802885@ci.pivotallabs.com.tmail> <4536CD13-2EAC-4BA1-87BF-B43C72BC0D02@zenspider.com> Message-ID: On Mon, Dec 13, 2010 at 1:46 AM, Chad Woolley wrote: >> Supported platforms are 1.8.7, 1.9.1, 1.9.2 > > Ok. ?If I set them up, are committers going to keep them green, or > question their necessity? ?If not, I've got better things to spend my > time on... And to be clear, I mean not committing to a red build. Options are fixing the code, fixing the test, reverting the failing commit, or commenting the test. Checking into a red build isn't an option, at least not if you're gonna want me to give a crap about maintaining the CI environment. Thanks, -- Chad From ryand-ruby at zenspider.com Mon Dec 13 06:02:12 2010 From: ryand-ruby at zenspider.com (Ryan Davis) Date: Mon, 13 Dec 2010 03:02:12 -0800 Subject: [Rubygems-developers] [CruiseControl] RubyGemsGitHub build 1e71d86 failed In-Reply-To: References: <4d04c791684d9_7270..fdbe313802885@ci.pivotallabs.com.tmail> <4536CD13-2EAC-4BA1-87BF-B43C72BC0D02@zenspider.com> Message-ID: <601C1D13-E1A7-4959-B4DA-5BB47DEA701B@zenspider.com> On Dec 13, 2010, at 00:46 , Chad Woolley wrote: > Ok. If I set them up, are committers going to keep them green, or > question their necessity? If not, I've got better things to spend my > time on... You do know that we don't have access to the CI, right? Kinda makes it unusable. From thewoolleyman at gmail.com Mon Dec 13 09:37:48 2010 From: thewoolleyman at gmail.com (Chad Woolley) Date: Mon, 13 Dec 2010 07:37:48 -0700 Subject: [Rubygems-developers] [CruiseControl] RubyGemsGitHub build 1e71d86 failed In-Reply-To: <601C1D13-E1A7-4959-B4DA-5BB47DEA701B@zenspider.com> References: <4d04c791684d9_7270..fdbe313802885@ci.pivotallabs.com.tmail> <4536CD13-2EAC-4BA1-87BF-B43C72BC0D02@zenspider.com> <601C1D13-E1A7-4959-B4DA-5BB47DEA701B@zenspider.com> Message-ID: On Mon, Dec 13, 2010 at 4:02 AM, Ryan Davis wrote: > > On Dec 13, 2010, at 00:46 , Chad Woolley wrote: > >> Ok. ?If I set them up, are committers going to keep them green, or >> question their necessity? ?If not, I've got better things to spend my >> time on... > > You do know that we don't have access to the CI, right? > > Kinda makes it unusable. Only if you cannot reproduce the error in the same interpreter locally using RVM. It's just an old ubuntu box; if I isolate the interpreters with RVM, the build should be completely reproducible. If you suspect there's something environment-specific on the box that broke the build, let me know. Finding out something like that would probably be a good thing, and perhaps something that should be fixed. And if it is really a problem that you can't get to the box, then I'll set it up on a dedicated VM and give the committers access. But, referencing a sentiment from a recent thread, I'd like to have a good REASON ;) -- Chad From ryand-ruby at zenspider.com Mon Dec 13 15:09:39 2010 From: ryand-ruby at zenspider.com (Ryan Davis) Date: Mon, 13 Dec 2010 12:09:39 -0800 Subject: [Rubygems-developers] [CruiseControl] RubyGemsGitHub build 1e71d86 failed In-Reply-To: References: <4d04c791684d9_7270..fdbe313802885@ci.pivotallabs.com.tmail> <4536CD13-2EAC-4BA1-87BF-B43C72BC0D02@zenspider.com> <601C1D13-E1A7-4959-B4DA-5BB47DEA701B@zenspider.com> Message-ID: <23ECE884-F959-46E7-A8BD-C042C951BB0D@zenspider.com> On Dec 13, 2010, at 06:37 , Chad Woolley wrote: > On Mon, Dec 13, 2010 at 4:02 AM, Ryan Davis wrote: >> >> On Dec 13, 2010, at 00:46 , Chad Woolley wrote: >> >>> Ok. If I set them up, are committers going to keep them green, or >>> question their necessity? If not, I've got better things to spend my >>> time on... >> >> You do know that we don't have access to the CI, right? >> >> Kinda makes it unusable. > > Only if you cannot reproduce the error in the same interpreter locally > using RVM. [...] How can I reproduce the error if I don't know what ruby impl + version + OS it was? The email says nothing about that. I have no other means of knowing as the urls that the mail sends out are inaccessible. Black boxes are not useful in this context. From thewoolleyman at gmail.com Mon Dec 13 21:28:47 2010 From: thewoolleyman at gmail.com (Chad Woolley) Date: Mon, 13 Dec 2010 19:28:47 -0700 Subject: [Rubygems-developers] [CruiseControl] RubyGemsGitHub build 1e71d86 failed In-Reply-To: <23ECE884-F959-46E7-A8BD-C042C951BB0D@zenspider.com> References: <4d04c791684d9_7270..fdbe313802885@ci.pivotallabs.com.tmail> <4536CD13-2EAC-4BA1-87BF-B43C72BC0D02@zenspider.com> <601C1D13-E1A7-4959-B4DA-5BB47DEA701B@zenspider.com> <23ECE884-F959-46E7-A8BD-C042C951BB0D@zenspider.com> Message-ID: On Mon, Dec 13, 2010 at 1:09 PM, Ryan Davis wrote: > How can I reproduce the error if I don't know what ruby impl + version + OS it was? The email says nothing about that. I have no other means of knowing as the urls that the mail sends out are inaccessible. Black boxes are not useful in this context. OK, working on fixing this. Sorry about the bad hostname, I fixed last month that but failed to restart the ci process properly, so it had the old one. I'll also spit out os/environment/interpreter/gem env info as part of the build output. The problem now is making the build happy with a dynamic RVM interpreter selection. How can I make Hoe's "check_extra_deps" not use sudo to install gems? Thx, -- Chad From thewoolleyman at gmail.com Mon Dec 13 23:17:27 2010 From: thewoolleyman at gmail.com (Chad Woolley) Date: Mon, 13 Dec 2010 21:17:27 -0700 Subject: [Rubygems-developers] CI Status (was: RubyGemsGitHub build 1e71d86 failed) Message-ID: I've got a working pass at a dynamic multi-interpreter build here (and it's green under 1.8.7): http://cibuilder.pivotallabs.com:3333/builds/RubyGems-1_8_7-p302 https://github.com/thewoolleyman/rubygems/tree/cifixes However, I had to hardcode and duplicate the dev gem dependency installation because I don't know how to make Hoe not use sudo for "check_extra_deps" Ryan, is there a way to not use sudo for "check_extra_deps"? Once I fix this, I can merge to master, make sure it's green, and turn back on notifications to list. Thx, -- Chad ---------- Forwarded message ---------- From: Chad Woolley Date: Mon, Dec 13, 2010 at 7:28 PM Subject: Re: [Rubygems-developers] [CruiseControl] RubyGemsGitHub build 1e71d86 failed To: RubyGems developers mailing list On Mon, Dec 13, 2010 at 1:09 PM, Ryan Davis wrote: > How can I reproduce the error if I don't know what ruby impl + version + OS it was? The email says nothing about that. I have no other means of knowing as the urls that the mail sends out are inaccessible. Black boxes are not useful in this context. OK, working on fixing this. ?Sorry about the bad hostname, I fixed last month that but failed to restart the ci process properly, so it had the old one. ?I'll also spit out os/environment/interpreter/gem env info as part of the build output. The problem now is making the build happy with a dynamic RVM interpreter selection. How can I make Hoe's "check_extra_deps" not use sudo to install gems? Thx, -- Chad From thewoolleyman at gmail.com Tue Dec 14 01:52:45 2010 From: thewoolleyman at gmail.com (Chad Woolley) Date: Mon, 13 Dec 2010 23:52:45 -0700 Subject: [Rubygems-developers] CI Status (was: RubyGemsGitHub build 1e71d86 failed) In-Reply-To: References: Message-ID: On Mon, Dec 13, 2010 at 9:17 PM, Chad Woolley wrote: > I've got a working pass at a dynamic multi-interpreter build here (and > it's green under 1.8.7): > > http://cibuilder.pivotallabs.com:3333/builds/RubyGems-1_8_7-p302 > https://github.com/thewoolleyman/rubygems/tree/cifixes > > However, I had to hardcode and duplicate the dev gem dependency > installation because I don't know how to make Hoe not use sudo for > "check_extra_deps" > > Ryan, is there a way to not use sudo for "check_extra_deps"? Here's builds for 1.9.1 and 1.9.2 as well. They seem to have some problems, which should be fixed before I enable build status notifications for them. These builds should be locally reproducible by invoking 'ci_build.sh '. Let me know if you think the problems are related to environment or misconfiguration: http://cibuilder.pivotallabs.com:3333/builds/RubyGems-1_9_1-p429 http://cibuilder.pivotallabs.com:3333/builds/RubyGems-1_9_2-rc2 Thx, -- Chad From jftucker at gmail.com Tue Dec 14 21:20:50 2010 From: jftucker at gmail.com (James Tucker) Date: Tue, 14 Dec 2010 18:20:50 -0800 Subject: [Rubygems-developers] Contributing to Ruby Projects In-Reply-To: <4882d3e4-0c5a-4c4d-8b15-bfd711dfb3f9@f21g2000prn.googlegroups.com> References: <4882d3e4-0c5a-4c4d-8b15-bfd711dfb3f9@f21g2000prn.googlegroups.com> Message-ID: <64ED47D6-B22E-4A6F-933B-0FF368F26A79@gmail.com> Wow, so, this thread is getting silly. It's just going to take some time for patches to get approved unless they're clearly ready. Anyway, there's some more feedback to come on comments here. Tying to snip where possible. On Dec 11, 2010, at 1:07 PM, Trans wrote: > On Dec 10, 1:55 am, Eric Hodel wrote: >> To begin with I would like to point out that you have deleted several of your comments forcing me to respond from memory and leaving their contents at the risk of "he-said, she-said". > > I did. I actually attempted to delete the all the commits altogether, > but it turns out that is not possible. It gets to a point were I would > rather delete them and forget the whole affair. You know there's fights that just aren't worth having, but that doesn't mean you should destroy work. > That request came only after I may a snarky remark about no one > commenting on the patch. From my perspective it appeared that when I > did something acceptable, it was being ignored. If it's not been merged in just a week or so, that's not ignored. A lot of the team are busy. > When I did something that wasn't it was an opportunity to "attack" (of course that > perception almost entirely has to do with Ryan). Something which pertains to one person seems to be off topic for the issues you raised here and on ruby-talk. >>> https://github.com/rubygems/rubygems/pull/12 > Of course there is always maintenance, but in the scheme of things, > this one is pretty small. What was it about 20-30 lines of code? Wrong. Sorry, but when it comes to specs, it's not the code, but the /format/ that requires maintenance. Once there's live dependencies or gems out there in particular formats, we have to support them forever. That really means forever. We still have to deal with old formats from way back when and it's in the way of other "innovation" already. Very careful design choices are the only way we can avoid this. It is this understanding that separates those who are judging your code from your "it's just 20-30 lines" line of thought. >> I asked if there were any non-ruby tools that used a YAML gemspec. If such a tool existed it might be a reason to consider this feature. >> >> You did not name any non-ruby tools that used a YAML gemspec, but you came up with some hypothetical ruby tools that could use this feature. You claimed that this feature was important because either RubyGems consumed too many resources or that it would not be available. > > You are asking for something that can't exist b/c there is no such > thing as a plain YAML gemspec. I was trying to create such a thing so > such tools could exist. > > I gave you three use cases, two where it could be helpful if loading > Rubygems were unnecessary (a web search app gathering info about > projects and a web-app to edit the YAML gemspec), and a case where it > can't be loaded (Setup.rb is an alternative installer, it does not > make any sense for it to load rubygems, but it could utilize a pure > YAML gemspec). rubygems master loads tons of less code. In fact, loading yaml is probably about the same speed once we disable the plugin lookup. Of course, what you're saying is that rubygems is too slow for this usage, but I don't see what webservice you're likely to write without rubygems. We can all imagine cases where people will do lots of different things. Coming up with cases that are provably useful is different. The issue here is that no one involved can see how your suggestion is provably useful. Furthermore, you could, in such a hypothetical service, just remove or implement the type hint in whatever bald yak environment you need to save a few hundred kb. Seems I'm having trouble with my tone too, I just can't see any sense in this. If you can't make it make sense then it's argument for the sake of argument. >> In brief, I responded that if it's a ruby tool it can use RubyGems and that RubyGems resource burden is not too large. As of Ruby 1.9 RubyGems is always available. (Adding a feature to RubyGems specifically for Ruby 1.8 requires an overwhelming need.) I believe this is where I closed the ticket as you could not come up with a satisfactory reason for including plain-YAML gemspecs. > > The thing is that you dismissed those use cases so quickly and so > summarily, that it seemed to me that you weren't really giving it that > much thought. I also made it very clear that good bit of the > motivation for this patch came from the fact that the Bundler folks > have been pushing people to move to hand-edited gemspecs. I was > actually surprised to learn that I was mistaken in thinking that was > also the stance of the Rubygems team. This has nothing to do with YAML or the use cases you described. If you feel your use cases are dismissed, explain them clearly, explain how it's new and relevant and useful, otherwise it's just a "what-if" and I can "what-if" like you have no idea. >> You persisted, however and I continued to respond. > >> You argued that it could be made "safer" and I referenced the past history of junk data in gemspecs and Jeremy Hindegardener's talk at RubyConf 2010 as a demonstration that it probably can't be made safer. > > Actually, I argued that it wasn't any less safe then it was already. I > only made a passing parenthetical comment that if type safety is a > concern that improvement could be made --but that applied to the > current design in general, not this particular feature. Actually, the real issue is that we cannot override parameters during a YAML load as that's down to the YAML library. This would mean adding stages to recomposition in order to remain backward compatible in future versions. In a ruby environment we already have a hook to take control of those things. Type safety is probably the wrong term. See the marshal load overrides for more information. >> You said it would be "more convenient" and I responded that I could not find a gem that used YAML in its .gemspec file in a few minutes of searching. I pointed out that the community has decided that the de-facto format for gemspec files is Ruby. >> >> I thought you would take my lack of discovery of YAML .gemspec files as an opportunity to show me a single project that used YAML in its gemspecs. This would demonstrate there was even a handful of RubyGems users who would benefit from this feature but you did not (or could not?). > > Again, I did show you and you simply dismissed those cases as people > "refusing to conform to best practices". Ore was the most obvious > example --it was so important for that developer that they went out of > their way to create a whole project devoted to doing it. That appears to be a single user that is doing this, in the entire ecosystem. Last industry statistics put our user count at supposedly close to 1 million users. That's less than 0.1%. I don't see any innovation or improvement over other methods. In fact, most of the project yaml files appear to be Gem::Specification yaml files, just with the type header removed. And you can't tell me that your resource argument is relevant: https://github.com/ruby-ore/ore-core/tree/master/lib/ore https://github.com/ruby-ore/ore-core/blob/master/lib/ore/project.rb this also seems to have missed the point of object serialization entirely. I could go on, but that's not why we're here. >> You pointed out ore which uses plain-YAML to create gemspecs and gems and used it as an argument in your favor. >> >> I responded that if ore supports this you should use ore as it does what you want already and requires no changes to RubyGems. Since you did not demonstrate that there was another RubyGems user who desires plain-YAML gemspecs I responded that there is only one person that wants this feature and that was not enough users to include it. I reiterated that the community has decided they prefer ruby. > >> If you look at the download counts, people overwhelmingly prefer to use ruby to build gems. Hoe has 690,000 and Jeweler has 56,000. Ore has 453. > > This is unreasonable argument. I can't provide examples of something > that CAN'T exist. Both Ore and my own tools took many man-hours to > make it possible --so that's not something one can reasonably expect > of the common community. Clearly most people are not going to do that. > The community is not getting much of an option. Ore is brand new. So > it's not really a fair indication. Ore really needs a lot of work, and by work I mean a lot of code deprecation. The same effect can be gathered using far less code. I appreciate people putting time into things they're passionate about, but that doesn't make those passions good ideas for us to support. There are people on crypto mailinglists putting far more time than either of you into new crypto ideas, but you don't expect us to support those signing algorithms. You say that this can't exist, but you also say that Ore does it. It's easy to make a gem specification from a yaml file, either typed or untyped: >> YAML.load_file('metadata').class => Hash >> spec = Gem::Specification.new => #=", #]]>, @loaded_from=nil, @has_rdoc=true, @specification_version=3, @original_platform=nil, @extra_rdoc_files=[], @files=[], @signing_key=nil, @default_executable=nil, @email=nil, @test_files=[], @required_ruby_version=#=", #]]>, @requirements=[], @rdoc_options=[], @rubygems_version="1.3.7", @homepage=nil, @name=nil, @executables=[], @platform="ruby", @autorequire=nil, @rubyforge_project=nil> >> YAML.load_file('metadata').each { |k,v| spec.send(k + '=', v) }; spec => # I'm out of steam and time. From noreply at rubyforge.org Fri Dec 17 01:35:25 2010 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 17 Dec 2010 01:35:25 -0500 (EST) Subject: [Rubygems-developers] [ rubygems-Bugs-26109 ] gem install gemname --remote will fail if gemname is in current directory Message-ID: <20101217063525.2D54E1858344@rubyforge.org> Bugs item #26109, was opened at 2009-06-02 17:03 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=26109&group_id=126 Category: `gem install` command Group: None Status: Closed Resolution: None Priority: 3 Submitted By: ara howard (ahoward) Assigned to: Nobody (None) Summary: gem install gemname --remote will fail if gemname is in current directory Initial Comment: gem install gemname --remote will prefer a gem in the current directory. seems like --remote should *never* do *anything* local? ---------------------------------------------------------------------- Comment By: Hirotsugu Asari (asarih) Date: 2010-12-17 00:35 Message: Ryan, Could this other ticket help your reproduce it? http://rubyforge.org/tracker/index.php?func=detail&aid=28481&group_id=126&atid=575 Also, `gem install` appears to search the local cache before querying remote sources, so if foo-1.0.0.dev1.gem exists in cache, it will be chosen, even when foo-1.0.0.gem (with seemingly more recent version number) is available on a remote server. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2010-11-12 16:46 Message: This ticket has been deemed stale and we're closing it in order to catch up with our ticket list. If you think it is still valid, please reopen. ---------------------------------------------------------------------- Comment By: Christof Spies (wingfire) Date: 2010-08-20 01:52 Message: gem env RubyGems Environment: - RUBYGEMS VERSION: 1.3.7 - RUBY VERSION: 1.8.7 (2008-08-11 patchlevel 72) [x86_64-linux] - INSTALLATION DIRECTORY: /usr/lib/ruby/gems/1.8 - RUBY EXECUTABLE: /usr/bin/ruby1.8 - EXECUTABLE DIRECTORY: /usr/bin - RUBYGEMS PLATFORMS: - ruby - x86_64-linux - GEM PATHS: - /usr/lib/ruby/gems/1.8 - /root/.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: Christof Spies (wingfire) Date: 2010-08-20 01:47 Message: I can confirm this issue. i.e. you have an outdated gem file in your home directory and run "gem update" from home then gem reinstall the old gem from the home directory. "gem update -r" is also "updating" with the outdated local gem. ---------------------------------------------------------------------- Comment By: Nick Hildebrant (nihildeb) Date: 2009-08-27 17:37 Message: Just familiarizing myself with the code here. I now see the issue. #find_gems_with_sources probably should only merge gem sources if @domain == :both also I don't see a case in which setting @domain = :local after rescuing a RemoteFetch exception would be useful or make sense ---------------------------------------------------------------------- Comment By: Nick Hildebrant (nihildeb) Date: 2009-08-26 15:54 Message: I can not reproduce this issue as a "preference". Rubygems appears to do remote as requested with requested gem in pwd. In the case of no network availability, the requested gem in the pwd is installed. This is as designed: Gem::DependencyInstaller#find_gems_with_sources rescues with @domain = :local RubyGems Environment: - RUBYGEMS VERSION: 1.3.3 - RUBY VERSION: 1.8.7 (2009-06-12 patchlevel 174) [x86_64-linux] - INSTALLATION DIRECTORY: /usr/lib/ruby/gems/1.8 - RUBY EXECUTABLE: /usr/bin/ruby - EXECUTABLE DIRECTORY: /usr/bin - RUBYGEMS PLATFORMS: - ruby - x86_64-linux - GEM PATHS: - /usr/lib/ruby/gems/1.8 - /home/nihildeb/.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 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=26109&group_id=126 From noreply at rubyforge.org Fri Dec 17 05:19:58 2010 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 17 Dec 2010 05:19:58 -0500 (EST) Subject: [Rubygems-developers] [ rubygems-Bugs-26109 ] gem install gemname --remote will fail if gemname is in current directory Message-ID: <20101217101958.6F5631858364@rubyforge.org> Bugs item #26109, was opened at 2009-06-02 15:03 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=26109&group_id=126 Category: `gem install` command Group: None >Status: Open Resolution: None Priority: 3 Submitted By: ara howard (ahoward) >Assigned to: John Barnette (jbarnette) Summary: gem install gemname --remote will fail if gemname is in current directory Initial Comment: gem install gemname --remote will prefer a gem in the current directory. seems like --remote should *never* do *anything* local? ---------------------------------------------------------------------- >Comment By: Ryan Davis (zenspider) Date: 2010-12-17 02:19 Message: Thanks Asari. Seems valid to me. Assigning to JB and leaving this one open since it also talks about local cache and there might be extra edge cases here. ---------------------------------------------------------------------- Comment By: Hirotsugu Asari (asarih) Date: 2010-12-16 22:35 Message: Ryan, Could this other ticket help your reproduce it? http://rubyforge.org/tracker/index.php?func=detail&aid=28481&group_id=126&atid=575 Also, `gem install` appears to search the local cache before querying remote sources, so if foo-1.0.0.dev1.gem exists in cache, it will be chosen, even when foo-1.0.0.gem (with seemingly more recent version number) is available on a remote server. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2010-11-12 14:46 Message: This ticket has been deemed stale and we're closing it in order to catch up with our ticket list. If you think it is still valid, please reopen. ---------------------------------------------------------------------- Comment By: Christof Spies (wingfire) Date: 2010-08-19 23:52 Message: gem env RubyGems Environment: - RUBYGEMS VERSION: 1.3.7 - RUBY VERSION: 1.8.7 (2008-08-11 patchlevel 72) [x86_64-linux] - INSTALLATION DIRECTORY: /usr/lib/ruby/gems/1.8 - RUBY EXECUTABLE: /usr/bin/ruby1.8 - EXECUTABLE DIRECTORY: /usr/bin - RUBYGEMS PLATFORMS: - ruby - x86_64-linux - GEM PATHS: - /usr/lib/ruby/gems/1.8 - /root/.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: Christof Spies (wingfire) Date: 2010-08-19 23:47 Message: I can confirm this issue. i.e. you have an outdated gem file in your home directory and run "gem update" from home then gem reinstall the old gem from the home directory. "gem update -r" is also "updating" with the outdated local gem. ---------------------------------------------------------------------- Comment By: Nick Hildebrant (nihildeb) Date: 2009-08-27 15:37 Message: Just familiarizing myself with the code here. I now see the issue. #find_gems_with_sources probably should only merge gem sources if @domain == :both also I don't see a case in which setting @domain = :local after rescuing a RemoteFetch exception would be useful or make sense ---------------------------------------------------------------------- Comment By: Nick Hildebrant (nihildeb) Date: 2009-08-26 13:54 Message: I can not reproduce this issue as a "preference". Rubygems appears to do remote as requested with requested gem in pwd. In the case of no network availability, the requested gem in the pwd is installed. This is as designed: Gem::DependencyInstaller#find_gems_with_sources rescues with @domain = :local RubyGems Environment: - RUBYGEMS VERSION: 1.3.3 - RUBY VERSION: 1.8.7 (2009-06-12 patchlevel 174) [x86_64-linux] - INSTALLATION DIRECTORY: /usr/lib/ruby/gems/1.8 - RUBY EXECUTABLE: /usr/bin/ruby - EXECUTABLE DIRECTORY: /usr/bin - RUBYGEMS PLATFORMS: - ruby - x86_64-linux - GEM PATHS: - /usr/lib/ruby/gems/1.8 - /home/nihildeb/.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 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=26109&group_id=126 From erik at hollensbe.org Thu Dec 16 06:08:08 2010 From: erik at hollensbe.org (Erik Hollensbe) Date: Thu, 16 Dec 2010 06:08:08 -0500 Subject: [Rubygems-developers] rubygems-test and gem-testers.org Message-ID: I'm proud to announce a (hopefully) rather important milestone in gem testing: http://www.gem-testers.org/gems/rubygems-test/ http://gem-testers.org Also, if you can find time, please gem install rubygems-test and try it out on a gem of yours (just add the stub file .gemtest to spec.files, and make sure rake test works from your created gem) and check out how the service interprets it. Test on-install testing and 'gem test', both should post to the service without error. Try to XSS attack it (really). Try to.. well, you get the idea. There are obviously going to be more than a few bugs here, so I'm not ready to "officially" announce anything, and I reserve the right to drop database at this point. Also, we need comments and criticism. Lots of it before we open the floodgates. And monitoring, but I'm working on that now. :) rubygems-test has an outstanding issue with bundler, so please be aware of that when using the bundler command to install anything (bundler will happily install it and rubygems-test will happily ask to uninstall it and bundler will happily say "sure!" and then report that it's been installed successfully. Patches were filed.). I'm not sure about other gem systems such as isolate, so comments there would help too. The rails app was written by a personal colleague of mine, Josiah Kiehl, another member of philly.rb. I think he's done a bang-up job with it, but if you have comments on how that should work, please ensure the Cc: line is preserved. He's busy as hell but I'll try to get him on the list here for the future. Code for the rails app is here: http://github.com/bluepojo/gem-testers Code for rubygems-test is here: http://github.com/erikh/rubygems-test -Erik From luislavena at gmail.com Sun Dec 19 18:15:42 2010 From: luislavena at gmail.com (Luis Lavena) Date: Sun, 19 Dec 2010 20:15:42 -0300 Subject: [Rubygems-developers] 1.4 and 1.9 branch? Message-ID: Hey guys, I've merged the code for one of the pull/feature contributions a few days ago, but search couldn't find the concrete logic against 1.4 and 1.9 branches. Is the code in 1.4 the one that is going to be released next? Shall I merge first there the new features and then merge to master? A good hint on the workflow will be great, 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 noreply at rubyforge.org Mon Dec 20 15:20:34 2010 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 20 Dec 2010 15:20:34 -0500 (EST) Subject: [Rubygems-developers] [ rubygems-Bugs-27154 ] Computed hash is sometimes too large. Message-ID: <20101220202034.5AEEF1858300@rubyforge.org> Bugs item #27154, was opened at 2009-09-21 07:42 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27154&group_id=126 Category: `gem install` command Group: None Status: Open Resolution: None Priority: 3 Submitted By: Ryan Riley (panesofglass) Assigned to: John Barnette (jbarnette) Summary: Computed hash is sometimes too large. Initial Comment: The current hash algorithm in dependency.rb (line 138) and specification.rb (line 658) can sometimes create a hash that is too large. This is also possible with Array#hash in MRI, which can also misbehave if one of the array elements returns a large hash value: class C def hash 100000000000000000000 end end [C.new].hash # => in `hash': bignum too big to convert into `long' (RangeError) REXML has a similar issue. http://redmine.ruby- lang.org/issues/show/1883 tracks the issue, and MRI will be fixing the issue. Suggested fixes are: edit: c:/ruby/libs/ruby/site_ruby/1.8/rubygems/dependency.rb;C840659 File: dependency.rb =================================================================== --- c:/ruby/libs/ruby/site_ruby/1.8/rubygems/dependency.rb;C840659 (server) 6/23/2009 1:21 PM +++ c:/ruby/libs/ruby/site_ruby/1.8/rubygems/dependency.rb @@ -112,7 +112,7 @@ end def hash # :nodoc: - name.hash + type.hash + version_requirements.hash + name.hash ^ type.hash ^ version_requirements.hash end end =================================================================== edit: c:/ruby/libs/ruby/site_ruby/1.8/rubygems/specification.rb;C908357 File: specification.rb =================================================================== --- c:/ruby/libs/ruby/site_ruby/1.8/rubygems/specification.rb;C908357 (server) 6/23/2009 1:24 PM +++ c:/ruby/libs/ruby/site_ruby/1.8/rubygems/specification.rb @@ -661,9 +661,8 @@ private :same_attributes? def hash # :nodoc: - @@attributes.inject(0) { |hash_code, (name, default_value)| - n = self.send(name).hash - hash_code + n + @@attributes.inject(612553) { |hash_code, (name, default_value)| + hash_code ^ self.send(name).hash } end =================================================================== ---------------------------------------------------------------------- Comment By: Daniel Weaver (zlern2k) Date: 2010-12-20 12:20 Message: I realize these are bugs in the underlying Ruby implementation of hash, but it really helps us to have them fixed in gem. This is the patch for requirement.rb that we currently need to deploy to make bundler happy with our apps: zlerntop:rubygems danielweaver$ diff -u requirement.rb.orig requirement.rb --- requirement.rb.orig 2010-12-20 12:13:40.000000000 -0800 +++ requirement.rb 2010-12-20 12:13:40.000000000 -0800 @@ -106,7 +106,7 @@ end def hash # :nodoc: - requirements.hash + requirements.inject(0) { |h, r| h ^ r.first.hash ^ r.last.hash } end def marshal_dump # :nodoc: ---------------------------------------------------------------------- Comment By: George Mendoza (gsmendoza) Date: 2010-12-06 20:06 Message: Hello again, I got the bignum error again, but this time with cucumber-0.9.4. These commands weren't able to install the gem: * bundle install * bundle install --local * sudo bundle install --local * sudo bundle install --local --system * sudo bundle install --system However, I was able to work around the issue by 1. installing the gem to my system manually (sudo gem install cucumber --version "0.9.4"), and 2. installing the bundle to the system (sudo bundle install --system) For step 2, trying "bundle install --local" worked only if all the gems in the bundle are already installed. If there were some gems from the bundle that are not installed, running "sudo bundle install --system" was the only way I could install them. George Mendoza Philippines ---------------------------------------------------------------------- Comment By: George Mendoza (gsmendoza) Date: 2010-11-30 19:52 Message: Hello, Appreciate if anybody can re-open this ticket. I am also getting the error when I try to install the dmitryv-backup gem via bundle. Please let me know if I need to provide any other information in order to fix this bug. Thanks! Gemfile: ---------------------------------------- source :rubygems source "http://gems.github.com" #... gem 'dmitryv-backup', '2.4.0', :require => "backup" #... ---------------------------------------- Running: ---------------------------------------- bundle install --local /usr/local/lib/site_ruby/1.8/rubygems/requirement.rb:109:in `hash': bignum too big to convert into `long' (RangeError) from /usr/local/lib/site_ruby/1.8/rubygems/requirement.rb:109:in `hash' from /usr/local/lib/site_ruby/1.8/rubygems/specification.rb:675:in `hash' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/index.rb:36:in `inject' from /usr/local/lib/site_ruby/1.8/rubygems/specification.rb:674:in `each' from /usr/local/lib/site_ruby/1.8/rubygems/specification.rb:674:in `inject' from /usr/local/lib/site_ruby/1.8/rubygems/specification.rb:674:in `hash' from /usr/lib/ruby/1.8/tsort.rb:204:in `include?' from /usr/lib/ruby/1.8/tsort.rb:204:in `each_strongly_connected_component_from' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/spec_set.rb:130:in `tsort_each_child' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/spec_set.rb:130:in `each' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/spec_set.rb:130:in `tsort_each_child' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/spec_set.rb:128:in `each' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/spec_set.rb:128:in `tsort_each_child' from /usr/lib/ruby/1.8/tsort.rb:203:in `each_strongly_connected_component_from' from /usr/lib/ruby/1.8/tsort.rb:209:in `each_strongly_connected_component_from' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/spec_set.rb:130:in `tsort_each_child' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/spec_set.rb:130:in `each' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/spec_set.rb:130:in `tsort_each_child' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/spec_set.rb:128:in `each' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/spec_set.rb:128:in `tsort_each_child' from /usr/lib/ruby/1.8/tsort.rb:203:in `each_strongly_connected_component_from' from /usr/lib/ruby/1.8/tsort.rb:182:in `each_strongly_connected_component' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/spec_set.rb:124:in `tsort_each_node' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/spec_set.rb:124:in `each' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/spec_set.rb:124:in `tsort_each_node' from /usr/lib/ruby/1.8/tsort.rb:180:in `each_strongly_connected_component' from /usr/lib/ruby/1.8/tsort.rb:148:in `tsort_each' from /usr/lib/ruby/1.8/tsort.rb:135:in `tsort' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/spec_set.rb:107:in `sorted' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/spec_set.rb:12:in `each' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/installer.rb:44:in `run' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/installer.rb:8:in `install' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/cli.rb:225:in `install' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/vendor/thor/task.rb:22:in `send' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/vendor/thor/task.rb:22:in `run' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/vendor/thor/invocation.rb:118:in `invoke_task' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/vendor/thor.rb:246:in `dispatch' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/vendor/thor/base.rb:389:in `start' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/bin/bundle:13 from /usr/bin/bundle:19:in `load' from /usr/bin/bundle:19 ---------------------------------------- Thanks, George Mendoza Philippines ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2010-11-12 14:46 Message: This ticket has been deemed stale and we're closing it in order to catch up with our ticket list. If you think it is still valid, please reopen. ---------------------------------------------------------------------- Comment By: Craig Cook (ccook) Date: 2010-10-18 14:08 Message: Hello, I tried this patch, but I am still getting the error, at the same place in the code. The error is the same with or without the patch to specification.rb; dependency.rb was already like the patched part shown above. This happened when installing using bundler, executed via capistrano. We had been using hpricot, it wasn't needed, it was giving this error first. I took it out, but then the same RangeError happened with mysql. I've seen it before also with nokogiri. (Always with native gems, though). Here's the relevant part of the log: ----------- begin log ---------------------------- ** [out :: 192.168.10.63] Installing mysql (2.8.1) ** [out :: 192.168.10.63] with native extensions ** [out :: 192.168.10.62] /usr/lib/ruby/site_ruby/1.8/rubygems/requirement.rb:109:in `hash' ** [out :: 192.168.10.62] : ** [out :: 192.168.10.62] bignum too big to convert into `long' ** [out :: 192.168.10.62] ( ** [out :: 192.168.10.62] RangeError ** [out :: 192.168.10.62] ) ** [out :: 192.168.10.62] from /usr/lib/ruby/site_ruby/1.8/rubygems/requirement.rb:109:in `hash' ** [out :: 192.168.10.62] from /usr/lib/ruby/site_ruby/1.8/rubygems/specification.rb:675:in `hash' ** [out :: 192.168.10.62] from /usr/lib/ruby/1.8/fileutils.rb:243:in `inject' ** [out :: 192.168.10.62] from /usr/lib/ruby/site_ruby/1.8/rubygems/specification.rb:674:in `each' ** [out :: 192.168.10.62] from /usr/lib/ruby/site_ruby/1.8/rubygems/specification.rb:674:in `inject' ** [out :: 192.168.10.62] from /usr/lib/ruby/site_ruby/1.8/rubygems/specification.rb:674:in `hash' ** [out :: 192.168.10.62] from /usr/lib/ruby/1.8/tsort.rb:205:in `include?' ** [out :: 192.168.10.62] from /usr/lib/ruby/1.8/tsort.rb:205:in `each_strongly_connected_component_from' ** [out :: 192.168.10.62] ... 22 levels... ** [out :: 192.168.10.62] from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.2/lib/bundler/vendor/thor/base.rb:389:in `start' ** [out :: 192.168.10.62] from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.2/bin/bundle:13 ** [out :: 192.168.10.62] from /usr/bin/bundle:19:in `load' ** [out :: 192.168.10.62] from /usr/bin/bundle:19 ----------- end cap output ------------------- running: ------------ system & ruby info ------------------ [ccook at ev2-stage ~]$ ruby -v ruby 1.8.7 (2010-08-16 patchlevel 302) [i686-linux] [ccook at ev2-stage ~]$ gem -v 1.3.7 [ccook at ev2-stage ~]$ uname -a Linux ev2-stage 2.6.18-194.11.4.el5xen #1 SMP Tue Sep 21 06:28:04 EDT 2010 i686 i686 i386 GNU/Linux ------ end system / ruby info ---------- Gemfile: ----------- begin Gemfile ----------------- source :gemcutter gem 'rails', '2.3.8' gem 'mysql', '2.8.1' gem "geokit" gem "geokit-rails" gem "builder" gem 'chronic' gem 'whenever' gem 'database_cleaner' gem 'apn_on_rails' gem 'factory_girl' gem 'net-sftp' gem 'will_paginate' # dependency for squirrel & jqgrid gem 'nokogiri' # only for test/functional/auth_controller_test.rb gem 'cucumber' gem 'cucumber-rails' gem 'webrat' gem 'rspec' ---------- end Gemfile ----------------- So, is this the same issue? It sure looks like it to me. I hope not to have to dive into the innards of rubygems if possible. But we need to be able to deploy. The app is working and passing tests on development, but hard to say on staging as we can't get it over there with cap. I suppose it could all be done by hand once anyway, but we (other dev on my team and I ) need to be able to do this over again. Thanks for your time in this! Cheers, Craig ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27154&group_id=126 From ryand-ruby at zenspider.com Tue Dec 21 04:47:42 2010 From: ryand-ruby at zenspider.com (Ryan Davis) Date: Tue, 21 Dec 2010 01:47:42 -0800 Subject: [Rubygems-developers] 1.4 and 1.9 branch? In-Reply-To: References: Message-ID: <65FFA487-A9D3-4BB3-8371-E0FCF6E22451@zenspider.com> On Dec 19, 2010, at 15:15 , Luis Lavena wrote: > I've merged the code for one of the pull/feature contributions a few > days ago, but search couldn't find the concrete logic against 1.4 and > 1.9 branches. > > Is the code in 1.4 the one that is going to be released next? Shall I > merge first there the new features and then merge to master? > > A good hint on the workflow will be great, thank you. Eric is in the rainforest and JB is MIA... so I'll take a stab at it and if I'm wrong, I'm sure I'll hear about it later :) The code in 1.4 is intended to be released next, and it is currently in a passing state (but... my git-fu is poor). As far as workflow goes, all development should go on master and then be merged to the 1.4 branch once sanctioned. and really... ALL master code should be merged to 1.4--we shouldn't be that far ahead of ourselves. I don't think the 1.9 branch is meant to stay, just to manage the chaos currently going on with ruby-core's rubygems vs ours. Once everything is reconciled, I think that branch should go away and all changes made to ruby-core's rubygems should be immediately rolled out without reservation. Otherwise it gets to be too much. Don't bother merging to it. We should be pushing from our release branch to ruby-core's svn as-is. From thewoolleyman at gmail.com Tue Dec 21 05:56:18 2010 From: thewoolleyman at gmail.com (Chad Woolley) Date: Tue, 21 Dec 2010 03:56:18 -0700 Subject: [Rubygems-developers] 1.4 and 1.9 branch? In-Reply-To: <65FFA487-A9D3-4BB3-8371-E0FCF6E22451@zenspider.com> References: <65FFA487-A9D3-4BB3-8371-E0FCF6E22451@zenspider.com> Message-ID: On Tue, Dec 21, 2010 at 2:47 AM, Ryan Davis wrote: > > On Dec 19, 2010, at 15:15 , Luis Lavena wrote: > >> I've merged the code for one of the pull/feature contributions a few >> days ago, but search couldn't find the concrete logic against 1.4 and >> 1.9 branches. >> >> Is the code in 1.4 the one that is going to be released next? Shall I >> merge first there the new features and then merge to master? >> >> A good hint on the workflow will be great, thank you. > > Eric is in the rainforest and JB is MIA... so I'll take a stab at it and if I'm wrong, I'm sure I'll hear about it later :) > > The code in 1.4 is intended to be released next, and it is currently in a passing state (but... my git-fu is poor). As far as workflow goes, all development should go on master and then be merged to the 1.4 branch once sanctioned. and really... ALL master code should be merged to 1.4--we shouldn't be that far ahead of ourselves. > > I don't think the 1.9 branch is meant to stay, just to manage the chaos currently going on with ruby-core's rubygems vs ours. Once everything is reconciled, I think that branch should go away and all changes made to ruby-core's rubygems should be immediately rolled out without reservation. Otherwise it gets to be too much. Don't bother merging to it. We should be pushing from our release branch to ruby-core's svn as-is. And, I'll use this as an opportunity to hijack this thread and mention that nobody responded to my thread requesting feedback on the CI improvements have ready to merge. Ryan broke the build. I bitched about broken windows. He said the CI system was broken. I fixed everything he said, as well as setting up all Eric's requested interpreters and showing how they are failing for me. Pointed everyone to my branch and asked what they'd like to do next. Fix the failing interpreters before I start spamming the list with broken builds, or after? No response. Which is why CI is hard. Not because it is hard to set up. Because it's hard to get people to care. Everybody says they give a shit. Most people don't want to put forth the effort to prove they give a shit. Peace, -- Chad From ryand-ruby at zenspider.com Tue Dec 21 16:10:18 2010 From: ryand-ruby at zenspider.com (Ryan Davis) Date: Tue, 21 Dec 2010 13:10:18 -0800 Subject: [Rubygems-developers] 1.4 and 1.9 branch? In-Reply-To: References: <65FFA487-A9D3-4BB3-8371-E0FCF6E22451@zenspider.com> Message-ID: <93FA9887-3EB6-423F-AB0E-F5E42ADD495F@zenspider.com> On Dec 21, 2010, at 02:56 , Chad Woolley wrote: > Which is why CI is hard. Not because it is hard to set up. Because > it's hard to get people to care. Everybody says they give a shit. > Most people don't want to put forth the effort to prove they give a > shit. Ya know... I'm done with your histrionics. Trans too. How about you both grow a pair and stop being such drama queens? Nobody here is paid to work on this shit. Nobody here is beholden to you or your invisible schedule. Nobody here feels the need to hold your hand to make sure you're getting enough attention. It has been a whopping EIGHT days since you sent out that last email. Now that my rant is over, I'll respond to your mail in that thread. From ryand-ruby at zenspider.com Tue Dec 21 16:16:20 2010 From: ryand-ruby at zenspider.com (Ryan Davis) Date: Tue, 21 Dec 2010 13:16:20 -0800 Subject: [Rubygems-developers] CI Status (was: RubyGemsGitHub build 1e71d86 failed) In-Reply-To: References: Message-ID: On Dec 13, 2010, at 22:52 , Chad Woolley wrote: > On Mon, Dec 13, 2010 at 9:17 PM, Chad Woolley wrote: >> I've got a working pass at a dynamic multi-interpreter build here (and >> it's green under 1.8.7): >> >> http://cibuilder.pivotallabs.com:3333/builds/RubyGems-1_8_7-p302 This is the latest version of 1.8.7 and runs clean. I dunno if you have control over this, but not having good titles on the HTML page makes distinguishing tabs a PITA. > http://cibuilder.pivotallabs.com:3333/builds/RubyGems-1_9_1-p429 p430 is the latest release on 1.9.1. This fails: > rake aborted! > no such file to load -- hoe > > /home/pivotal/.cruise/projects/RubyGems-1_9_1-p429/work/Rakefile:8 > :in `require' So, environmental problem here... > http://cibuilder.pivotallabs.com:3333/builds/RubyGems-1_9_2-rc2 p0 is the latest release for 1.9.2. Why is it building ruby on every run? This one has failures, but they're not visible in the CI. I suspect it is just truncating because of the annoying YAML warning on a billion lines. If I click on the raw log they're all: > /home/pivotal/.rvm/rubies/ruby-1.9.2-rc2/lib/ruby/1.9.1/rubygems.rb:335:in `bin_path': can't find executable rake for rake-0.8.7 (Gem::Exception) So I suspect something environmental still. From thewoolleyman at gmail.com Tue Dec 21 16:51:59 2010 From: thewoolleyman at gmail.com (Chad Woolley) Date: Tue, 21 Dec 2010 14:51:59 -0700 Subject: [Rubygems-developers] 1.4 and 1.9 branch? In-Reply-To: <93FA9887-3EB6-423F-AB0E-F5E42ADD495F@zenspider.com> References: <65FFA487-A9D3-4BB3-8371-E0FCF6E22451@zenspider.com> <93FA9887-3EB6-423F-AB0E-F5E42ADD495F@zenspider.com> Message-ID: On Tue, Dec 21, 2010 at 2:10 PM, Ryan Davis wrote: > > On Dec 21, 2010, at 02:56 , Chad Woolley wrote: > >> Which is why CI is hard. ?Not because it is hard to set up. ?Because >> it's hard to get people to care. ?Everybody says they give a shit. >> Most people don't want to put forth the effort to prove they give a >> shit. > > Ya know... I'm done with your histrionics. Trans too. How about you both grow a pair and stop being such drama queens? Nobody here is paid to work on this shit. Nobody here is beholden to you or your invisible schedule. Nobody here feels the need to hold your hand to make sure you're getting enough attention. It has been a whopping EIGHT days since you sent out that last email. > > Now that my rant is over, I'll respond to your mail in that thread. I love you too :) From ryand-ruby at zenspider.com Tue Dec 21 20:00:48 2010 From: ryand-ruby at zenspider.com (Ryan Davis) Date: Tue, 21 Dec 2010 17:00:48 -0800 Subject: [Rubygems-developers] The 1.9 Plan Message-ID: I just pulled the rubygems in ruby-core's trunk into our 1.9 branch and tweaked it enough to make it pass under 1.8.7. The changes were minimal to lib and mostly just annoying in test. I've pushed this back up so that others can review. Moving forward: + I'm prolly gonna move everything from test/* to test/rubygems/* to match ruby-core. They switched us to require_relative on everything (ugh). + We need to selectively pull additions and changes from the 1.9 branch to master. + I don't have a handle on what (or why) changes have happened on ruby trunk. + Input is welcome. + It is about 3k line o' diff. Help is welcome too. + Once we reconcile differences between the 1.9 branch and master, we nuke the 1.9 branch and push all our changes to ruby trunk. + ruby trunk pushes will be automated and include a warning header in every file. + Any changes that occur in ruby trunk will be reverted immediately. + I'd rather push every single day to ruby trunk than to ever do this reconciliation again. Raggi says that he's close to a rack release, which is the big blocker for rails, which is our big blocker. He estimates the dam will break sometime this week and we'll be free to release after that. Luis, consider this your heads-up that we're close to release... From luislavena at gmail.com Wed Dec 22 08:17:29 2010 From: luislavena at gmail.com (Luis Lavena) Date: Wed, 22 Dec 2010 10:17:29 -0300 Subject: [Rubygems-developers] The 1.9 Plan In-Reply-To: References: Message-ID: On Tue, Dec 21, 2010 at 10:00 PM, Ryan Davis wrote: > > Luis, consider this your heads-up that we're close to release... Thank you. I'm going to merge the --launch command for "gem server" into 1.4 I'm still not 100% sure what you're expecting from us in relation to merge ruby-trunk changes. -- 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 headius at headius.com Wed Dec 22 13:41:02 2010 From: headius at headius.com (Charles Oliver Nutter) Date: Wed, 22 Dec 2010 12:41:02 -0600 Subject: [Rubygems-developers] Status of disabling plugins except for command line? Message-ID: Hey all! I wanted to see if there's been any progress getting plugins to load only when using the 'gem' command. Currently, because they're loaded at the bottom of rubygems.rb, every app that needs rubygems incurs a massive startup hit to scan for plugins in all installed gems. On JRuby, on my system with 500+ gems installed, this takes several seconds. I have been recommending that users sensitive to this startup hit comment out that code or move it to gem_runner.rb, which gets loaded directly from the gem command. I talked with James Tucker about the status, and he said I should check here. He also said he thought this move had been attempted, but that it broke something else. We're hoping to ship JRuby 1.6 RCs in the next couple weeks, and it would be really great if we could include some fix for the plugin startup hit. So, what's up? - Charlie From luislavena at gmail.com Wed Dec 22 13:52:39 2010 From: luislavena at gmail.com (Luis Lavena) Date: Wed, 22 Dec 2010 15:52:39 -0300 Subject: [Rubygems-developers] Status of disabling plugins except for command line? In-Reply-To: References: Message-ID: On Wed, Dec 22, 2010 at 3:41 PM, Charles Oliver Nutter wrote: > Hey all! > > I wanted to see if there's been any progress getting plugins to load > only when using the 'gem' command. Currently, because they're loaded > at the bottom of rubygems.rb, every app that needs rubygems incurs a > massive startup hit to scan for plugins in all installed gems. On > JRuby, on my system with 500+ gems installed, this takes several > seconds. > > I have been recommending that users sensitive to this startup hit > comment out that code or move it to gem_runner.rb, which gets loaded > directly from the gem command. > > I talked with James Tucker about the status, and he said I should > check here. He also said he thought this move had been attempted, but > that it broke something else. > > We're hoping to ship JRuby 1.6 RCs in the next couple weeks, and it > would be really great if we could include some fix for the plugin > startup hit. > > So, what's up? > This is the ticket: http://rubyforge.org/tracker/index.php?func=detail&aid=27422&group_id=126&atid=578 And the code done by James Tucker (raggi) was never merged back to master/1.4 branch -- 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 headius at headius.com Wed Dec 22 14:33:25 2010 From: headius at headius.com (Charles Oliver Nutter) Date: Wed, 22 Dec 2010 13:33:25 -0600 Subject: [Rubygems-developers] Status of disabling plugins except for command line? In-Reply-To: References: Message-ID: On Wed, Dec 22, 2010 at 12:52 PM, Luis Lavena wrote: > This is the ticket: > > http://rubyforge.org/tracker/index.php?func=detail&aid=27422&group_id=126&atid=578 > > And the code done by James Tucker (raggi) was never merged back to > master/1.4 branch Here's my na?ve change and the impact to perf with around 500 installed gems: https://gist.github.com/751969 This hasn't broken anything for me, but I haven't done any intensive testing. The startup improvement is shocking. - Charlie From luislavena at gmail.com Wed Dec 22 14:45:31 2010 From: luislavena at gmail.com (Luis Lavena) Date: Wed, 22 Dec 2010 16:45:31 -0300 Subject: [Rubygems-developers] Status of disabling plugins except for command line? In-Reply-To: References: Message-ID: On Wed, Dec 22, 2010 at 4:33 PM, Charles Oliver Nutter wrote: > On Wed, Dec 22, 2010 at 12:52 PM, Luis Lavena wrote: >> This is the ticket: >> >> http://rubyforge.org/tracker/index.php?func=detail&aid=27422&group_id=126&atid=578 >> >> And the code done by James Tucker (raggi) was never merged back to >> master/1.4 branch > > Here's my na?ve change and the impact to perf with around 500 installed gems: > > https://gist.github.com/751969 > > This hasn't broken anything for me, but I haven't done any intensive > testing. The startup improvement is shocking. > I like your patch, will test later tonight against some gem plugins I have installed and see if something broke. For a quick and dirty fix is very very amazing improvement. 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 ryand-ruby at zenspider.com Wed Dec 22 17:32:59 2010 From: ryand-ruby at zenspider.com (Ryan Davis) Date: Wed, 22 Dec 2010 14:32:59 -0800 Subject: [Rubygems-developers] The 1.9 Plan In-Reply-To: References: Message-ID: On Dec 22, 2010, at 05:17 , Luis Lavena wrote: > On Tue, Dec 21, 2010 at 10:00 PM, Ryan Davis wrote: >> >> Luis, consider this your heads-up that we're close to release... > > Thank you. > > I'm going to merge the --launch command for "gem server" into 1.4 kk > I'm still not 100% sure what you're expecting from us in relation to > merge ruby-trunk changes. We've got a lot of changes (mostly additions?) on trunk that aren't in 1.4. If we're going to release 1.4 soon I say we push it as close to as-is as possible. JB intended 1.4 to be a "holy crap we haven't pushed anything in 7 months! PUSH NOW!!". We will do a 1.5 in a month (4-6 weeks from this release). From ryand-ruby at zenspider.com Wed Dec 22 17:37:12 2010 From: ryand-ruby at zenspider.com (Ryan Davis) Date: Wed, 22 Dec 2010 14:37:12 -0800 Subject: [Rubygems-developers] Status of disabling plugins except for command line? In-Reply-To: References: Message-ID: <8390C5FB-19BF-4ED5-A6E2-5B4FD58BEEC9@zenspider.com> On Dec 22, 2010, at 11:45 , Luis Lavena wrote: > I like your patch, will test later tonight against some gem plugins I > have installed and see if something broke. For a quick and dirty fix > is very very amazing improvement. I like it too. seems safe enough tho I didn't test it directly. Raggi? What do you think? I think this (or equiv) is a mandatory change for 1.4 to go out. From headius at headius.com Wed Dec 22 17:50:14 2010 From: headius at headius.com (Charles Oliver Nutter) Date: Wed, 22 Dec 2010 16:50:14 -0600 Subject: [Rubygems-developers] Status of disabling plugins except for command line? In-Reply-To: <8390C5FB-19BF-4ED5-A6E2-5B4FD58BEEC9@zenspider.com> References: <8390C5FB-19BF-4ED5-A6E2-5B4FD58BEEC9@zenspider.com> Message-ID: On Wed, Dec 22, 2010 at 4:37 PM, Ryan Davis wrote: > I like it too. seems safe enough tho I didn't test it directly. > > Raggi? What do you think? > > I think this (or equiv) is a mandatory change for 1.4 to go out. I agree. Perhaps most people don't have 500 gems installed, but everyone I've suggested this fix to has told me it made a tremendous difference. - Charlie From headius at headius.com Wed Dec 22 17:56:36 2010 From: headius at headius.com (Charles Oliver Nutter) Date: Wed, 22 Dec 2010 16:56:36 -0600 Subject: [Rubygems-developers] Status of disabling plugins except for command line? In-Reply-To: References: Message-ID: On Wed, Dec 22, 2010 at 1:33 PM, Charles Oliver Nutter wrote: > Here's my na?ve change and the impact to perf with around 500 installed gems: > > https://gist.github.com/751969 A note of clarification... the first two times there are without the patch (obviously), and the first time is with an uncached filesystem (cold). So you kinda can see worst and best-case performance scanning 500 gems for plugins under JRuby. I'm guessing there's also potential fixes for that scanning process, all the way up to caching lists plugins on install (i.e. eliminating future scans altogether), but this is a good quick fix for non-command-line rubygems use. - Charlie From jftucker at gmail.com Wed Dec 22 22:46:12 2010 From: jftucker at gmail.com (James Tucker) Date: Wed, 22 Dec 2010 22:46:12 -0500 Subject: [Rubygems-developers] Status of disabling plugins except for command line? In-Reply-To: References: Message-ID: <9950C8A3-D256-457D-BC69-BB20F2CEC35F@gmail.com> On Dec 22, 2010, at 5:56 PM, Charles Oliver Nutter wrote: > On Wed, Dec 22, 2010 at 1:33 PM, Charles Oliver Nutter > wrote: >> Here's my na?ve change and the impact to perf with around 500 installed gems: >> >> https://gist.github.com/751969 > > A note of clarification... the first two times there are without the > patch (obviously), and the first time is with an uncached filesystem > (cold). So you kinda can see worst and best-case performance scanning > 500 gems for plugins under JRuby. > > I'm guessing there's also potential fixes for that scanning process, > all the way up to caching lists plugins on install (i.e. eliminating > future scans altogether), but this is a good quick fix for > non-command-line rubygems use. +1 on this patch for now. Some more details: - This is kind of the phase 1 plan, although if there was more time available I've had avoided doing this. - This will break 4 gem plugins, mostly minor and I've never seen them used 'in the wild'. I have the list knocking around somewhere, I'll dig it up if someone reminds me when I'm awake. - There have been no objections so far except from Erik Hollensbe, I think it's related to his recent gem testing plugin. We can provide hooks for him in a future version. - Which brings me to phase 2: * Plugins should actually activate the gems they're loaded from (otherwise we have double-loads double versions, blah blah) * Plugin files should have a way to hook without actually /loading code/. (f.e. "load me before running commands") * Plugin file locations should be cached separately to avoid having to walk the source index. This index should only include the 'latest gem' for each gem containing a plugin. It would be updated on install and uninstall. * Plugin loading must have a generic --no-plugins option in the gem command, so that broken plugins don't require manual removal. From headius at headius.com Wed Dec 22 22:59:23 2010 From: headius at headius.com (Charles Oliver Nutter) Date: Wed, 22 Dec 2010 21:59:23 -0600 Subject: [Rubygems-developers] Status of disabling plugins except for command line? In-Reply-To: <9950C8A3-D256-457D-BC69-BB20F2CEC35F@gmail.com> References: <9950C8A3-D256-457D-BC69-BB20F2CEC35F@gmail.com> Message-ID: On Wed, Dec 22, 2010 at 9:46 PM, James Tucker wrote: > +1 on this patch for now. > > > Some more details: > > ?- This is kind of the phase 1 plan, although if there was more time available I've had avoided doing this. > ?- This will break 4 gem plugins, mostly minor and I've never seen them used 'in the wild'. I have the list knocking around somewhere, I'll dig it up if someone reminds me when I'm awake. > ?- There have been no objections so far except from Erik Hollensbe, I think it's related to his recent gem testing plugin. We can provide hooks for him in a future version. For my part, I'll proactively make this commit to JRuby and see what havoc (if any) it wreaks on our CI runs and bleeding-edge users. - Charlie From ryand-ruby at zenspider.com Thu Dec 23 01:42:36 2010 From: ryand-ruby at zenspider.com (Ryan Davis) Date: Wed, 22 Dec 2010 22:42:36 -0800 Subject: [Rubygems-developers] Status of disabling plugins except for command line? In-Reply-To: <8390C5FB-19BF-4ED5-A6E2-5B4FD58BEEC9@zenspider.com> References: <8390C5FB-19BF-4ED5-A6E2-5B4FD58BEEC9@zenspider.com> Message-ID: On Dec 22, 2010, at 14:37 , Ryan Davis wrote: > > On Dec 22, 2010, at 11:45 , Luis Lavena wrote: > >> I like your patch, will test later tonight against some gem plugins I >> have installed and see if something broke. For a quick and dirty fix >> is very very amazing improvement. > > I like it too. seems safe enough tho I didn't test it directly. > > Raggi? What do you think? > > I think this (or equiv) is a mandatory change for 1.4 to go out. I've committed this patch and pushed it to master. From transfire at gmail.com Thu Dec 23 04:08:18 2010 From: transfire at gmail.com (Trans) Date: Thu, 23 Dec 2010 01:08:18 -0800 (PST) Subject: [Rubygems-developers] Status of disabling plugins except for command line? In-Reply-To: <9950C8A3-D256-457D-BC69-BB20F2CEC35F@gmail.com> References: <9950C8A3-D256-457D-BC69-BB20F2CEC35F@gmail.com> Message-ID: On Dec 22, 10:46?pm, James Tucker wrote: > On Dec 22, 2010, at 5:56 PM, Charles Oliver Nutter wrote: > > > On Wed, Dec 22, 2010 at 1:33 PM, Charles Oliver Nutter > > wrote: > >> Here's my na?ve change and the impact to perf with around 500 installed gems: > > >>https://gist.github.com/751969 > > > I'm guessing there's also potential fixes for that scanning process, > > all the way up to caching lists plugins on install (i.e. eliminating > > future scans altogether), but this is a good quick fix for > > non-command-line rubygems use. > > +1 on this patch for now. -1 _for now_. > ?- This will break 4 gem plugins, mostly minor and I've never seen them used 'in the wild'. I have the list knocking around somewhere, I'll dig it up if someone reminds me when I'm awake. I know of at least two gems it will break, and I suspect they are not your four. I thought RubyGems was supposed to be so *conservative* about changes, and here a change is just going to be pushed that breaks people's plugins for the sake of a speed up for those who have 500+ gems installed? Overlooking the fact that there other solutions to deal with large gem collections, like rvm's gemsets. Why wouldn't the prudent course of action be to actually fix this _correctly now_, rather than implement a "phase 1" change that will leave certain types of plugins out in the cold for who knows how long? If that's asking too much, then at the very least, make this patch a configurable option in the .gemrc file. Power users who aren't using any of the above mentioned plugins could then easily flip the switch to get the speed up. From headius at headius.com Thu Dec 23 04:24:49 2010 From: headius at headius.com (Charles Oliver Nutter) Date: Thu, 23 Dec 2010 03:24:49 -0600 Subject: [Rubygems-developers] Status of disabling plugins except for command line? In-Reply-To: References: <9950C8A3-D256-457D-BC69-BB20F2CEC35F@gmail.com> Message-ID: On Thu, Dec 23, 2010 at 3:08 AM, Trans wrote: > I know of at least two gems it will break, and I suspect they are not > your four. You guys with your mystery lists. Spill it, man! > I thought RubyGems was supposed to be so *conservative* about changes, > and here a change is just going to be pushed that breaks people's > plugins for the sake of a speed up for those who have 500+ gems > installed? It's not just a problem for 500+, it's a problem for anyone who installs, say, Rails 3's several dozen dependencies. Globbing through all those directories gets linearly slower, and even people with just a few gems will notice a startup improvement from this. The right answer is that plugins should NEVER have been auto-discovered with a filesystem scan on every startup since that's inherently O(N) as more gems are introduced (and especially bad on implementations that already have startup concerns like JRuby or Rubinius). So I feel more like we're righting an over-eager change (plugins scanned on every load of 'rubygems') by backing off the most egregious aspect of that decision. We're not breaking good behavior, we're rolling back bad behavior. I call that a bug fix. > Overlooking the fact that there other solutions to deal with large gem > collections, like rvm's gemsets. Why wouldn't the prudent course of > action be to actually fix this _correctly now_, rather than implement > a "phase 1" change that will leave certain types of plugins out in the > cold for who knows how long? > > If that's asking too much, then at the very least, make this patch a > configurable option in the .gemrc file. Power users who aren't using > any of the above mentioned plugins could then easily flip the switch > to get the speed up. No plugins have been mentioned :) All I see are shadows and spectres. I want to know what these plugins are and why this change breaks them. If there's additional changes required to keep them working, we can discuss that. But having a simple load of 'rubygems' scan the filesystem every freaking time is a nonstarter (and should always have been). - Charlie From headius at headius.com Thu Dec 23 05:42:03 2010 From: headius at headius.com (Charles Oliver Nutter) Date: Thu, 23 Dec 2010 04:42:03 -0600 Subject: [Rubygems-developers] Status of disabling plugins except for command line? In-Reply-To: References: <9950C8A3-D256-457D-BC69-BB20F2CEC35F@gmail.com> Message-ID: FYI, Eric Hollensbe pinged me on Twitter to say that this change does not appear to break his gem. So that's at least one confirmed ok. He also said his messages keep getting moderated into oblivion. Someone might want to see to that. On Thu, Dec 23, 2010 at 3:24 AM, Charles Oliver Nutter wrote: > On Thu, Dec 23, 2010 at 3:08 AM, Trans wrote: >> I know of at least two gems it will break, and I suspect they are not >> your four. > > You guys with your mystery lists. Spill it, man! > >> I thought RubyGems was supposed to be so *conservative* about changes, >> and here a change is just going to be pushed that breaks people's >> plugins for the sake of a speed up for those who have 500+ gems >> installed? > > It's not just a problem for 500+, it's a problem for anyone who > installs, say, Rails 3's several dozen dependencies. Globbing through > all those directories gets linearly slower, and even people with just > a few gems will notice a startup improvement from this. > > The right answer is that plugins should NEVER have been > auto-discovered with a filesystem scan on every startup since that's > inherently O(N) as more gems are introduced (and especially bad on > implementations that already have startup concerns like JRuby or > Rubinius). So I feel more like we're righting an over-eager change > (plugins scanned on every load of 'rubygems') by backing off the most > egregious aspect of that decision. We're not breaking good behavior, > we're rolling back bad behavior. I call that a bug fix. > >> Overlooking the fact that there other solutions to deal with large gem >> collections, like rvm's gemsets. Why wouldn't the prudent course of >> action be to actually fix this _correctly now_, rather than implement >> a "phase 1" change that will leave certain types of plugins out in the >> cold for who knows how long? >> >> If that's asking too much, then at the very least, make this patch a >> configurable option in the .gemrc file. Power users who aren't using >> any of the above mentioned plugins could then easily flip the switch >> to get the speed up. > > No plugins have been mentioned :) All I see are shadows and spectres. > > I want to know what these plugins are and why this change breaks them. > If there's additional changes required to keep them working, we can > discuss that. But having a simple load of 'rubygems' scan the > filesystem every freaking time is a nonstarter (and should always have > been). > > - Charlie > From ryand-ruby at zenspider.com Thu Dec 23 05:45:24 2010 From: ryand-ruby at zenspider.com (Ryan Davis) Date: Thu, 23 Dec 2010 02:45:24 -0800 Subject: [Rubygems-developers] Status of disabling plugins except for command line? In-Reply-To: References: <9950C8A3-D256-457D-BC69-BB20F2CEC35F@gmail.com> Message-ID: On Dec 23, 2010, at 01:08 , Trans wrote: > I know of at least two gems it will break, and I suspect they are not > your four. By not telling us what they are, you're being immature and asinine... and a troll. *sigh* You can just never stop trolling... > I thought RubyGems was supposed to be so *conservative* about changes, > and here a change is just going to be pushed that breaks people's > plugins for the sake of a speed up for those who have 500+ gems > installed? Apparently you're confusing us breaking 2-4 gems in a way that is easily documentable with your breaking every gemspec ever published. This is the conservative change. Do the math. I ... nevermind. I just deleted 3 paragraphs... I'm not going to justify our actions any further with a troll. From ryand-ruby at zenspider.com Thu Dec 23 06:23:19 2010 From: ryand-ruby at zenspider.com (Ryan Davis) Date: Thu, 23 Dec 2010 03:23:19 -0800 Subject: [Rubygems-developers] Status of disabling plugins except for command line? In-Reply-To: References: <9950C8A3-D256-457D-BC69-BB20F2CEC35F@gmail.com> Message-ID: <971CCE37-0F30-40EE-AE9B-BC134DA9E33E@zenspider.com> On Dec 23, 2010, at 02:42 , Charles Oliver Nutter wrote: > FYI, Eric Hollensbe pinged me on Twitter to say that this change does > not appear to break his gem. So that's at least one confirmed ok. Awesome. Thanks for the data. We can also write a gauntlet script that will test against all gems. > He also said his messages keep getting moderated into oblivion. > Someone might want to see to that. I'll make sure Eric deals with that once he gets back. Thanks for the reminder. From luislavena at gmail.com Thu Dec 23 07:23:59 2010 From: luislavena at gmail.com (Luis Lavena) Date: Thu, 23 Dec 2010 09:23:59 -0300 Subject: [Rubygems-developers] Status of disabling plugins except for command line? In-Reply-To: References: <9950C8A3-D256-457D-BC69-BB20F2CEC35F@gmail.com> Message-ID: On Thu, Dec 23, 2010 at 7:42 AM, Charles Oliver Nutter wrote: > FYI, Eric Hollensbe pinged me on Twitter to say that this change does > not appear to break his gem. So that's at least one confirmed ok. > This change doesn't break "gem open" plugin either: https://rubygems.org/gems/gem-open PS: A friendly reminder that most gem plugins extend "gem" command, not the loading of rubygems. The ones I know: gemcutter yard gem-open Works. -- 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 darix at web.de Thu Dec 23 10:23:42 2010 From: darix at web.de (Marcus Rueckert) Date: Thu, 23 Dec 2010 16:23:42 +0100 Subject: [Rubygems-developers] Status of disabling plugins except for command line? In-Reply-To: References: <9950C8A3-D256-457D-BC69-BB20F2CEC35F@gmail.com> Message-ID: <20101223152342.GL16502@nordisch.org> On 2010-12-23 01:08:18 -0800, Trans wrote: > Overlooking the fact that there other solutions to deal with large gem > collections, like rvm's gemsets. Why wouldn't the prudent course of > action be to actually fix this _correctly now_, rather than implement > a "phase 1" change that will leave certain types of plugins out in the > cold for who knows how long? not everyone can/wants to use rvm. also having a 3rd party tool solution to solve a problem which can be solved in gem seems just wrong. for me having plugins to register themself explicitely seems to be the way to go. darix -- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org From transfire at gmail.com Thu Dec 23 10:55:27 2010 From: transfire at gmail.com (Trans) Date: Thu, 23 Dec 2010 07:55:27 -0800 (PST) Subject: [Rubygems-developers] Status of disabling plugins except for command line? In-Reply-To: References: <9950C8A3-D256-457D-BC69-BB20F2CEC35F@gmail.com> Message-ID: On Dec 23, 4:24?am, Charles Oliver Nutter wrote: > On Thu, Dec 23, 2010 at 3:08 AM, Trans wrote: > > I know of at least two gems it will break, and I suspect they are not > > your four. > > You guys with your mystery lists. Spill it, man! The two I know of are gem-wedge and ore. Ore is especially ironic, b/c I was recently told that RubyGems did not need to support plain YAML specs itself b/c a plugin, like Ore, could do the job. > > I thought RubyGems was supposed to be so *conservative* about changes, > > and here a change is just going to be pushed that breaks people's > > plugins for the sake of a speed up for those who have 500+ gems > > installed? > > It's not just a problem for 500+, it's a problem for anyone who > installs, say, Rails 3's several dozen dependencies. Globbing through > all those directories gets linearly slower, and even people with just > a few gems will notice a startup improvement from this. > > The right answer is that plugins should NEVER have been > auto-discovered with a filesystem scan on every startup since that's > inherently O(N) as more gems are introduced (and especially bad on > implementations that already have startup concerns like JRuby or > Rubinius). Doesn't the file system itself cache the file access, so after the first run it speeds up for every subsequent use? So it's not quite that bad. But to be sure I am not against fixing this, I just don't want to see non-command plugins broken to do it. > So I feel more like we're righting an over-eager change > (plugins scanned on every load of 'rubygems') by backing off the most > egregious aspect of that decision. We're not breaking good behavior, > we're rolling back bad behavior. I call that a bug fix. One man's bug is another man's feature ;) > > Overlooking the fact that there other solutions to deal with large gem > > collections, like rvm's gemsets. Why wouldn't the prudent course of > > action be to actually fix this _correctly now_, rather than implement > > a "phase 1" change that will leave certain types of plugins out in the > > cold for who knows how long? > > > If that's asking too much, then at the very least, make this patch a > > configurable option in the .gemrc file. Power users who aren't using > > any of the above mentioned plugins could then easily flip the switch > > to get the speed up. > > No plugins have been mentioned :) All I see are shadows and spectres. > > I want to know what these plugins are and why this change breaks them. > If there's additional changes required to keep them working, we can > discuss that. But having a simple load of 'rubygems' scan the > filesystem every freaking time is a nonstarter (and should always have > been). No, it was a shortcut then, and now another shortcut is being made to remedy the first. A real solution would check for a plugins at install time, if one is found copy it to a special location, e.g. gems/plugins, in much the same way that a gem's specification is copied to a special location. Then when Rubygems is loaded there is no need to search the file system, all the plugins are in one place. From erik at hollensbe.org Wed Dec 22 18:03:00 2010 From: erik at hollensbe.org (Erik Hollensbe) Date: Wed, 22 Dec 2010 18:03:00 -0500 Subject: [Rubygems-developers] Status of disabling plugins except for command line? In-Reply-To: <8390C5FB-19BF-4ED5-A6E2-5B4FD58BEEC9@zenspider.com> References: <8390C5FB-19BF-4ED5-A6E2-5B4FD58BEEC9@zenspider.com> Message-ID: On Dec 22, 2010, at 5:37 PM, Ryan Davis wrote: > > On Dec 22, 2010, at 11:45 , Luis Lavena wrote: > >> I like your patch, will test later tonight against some gem plugins I >> have installed and see if something broke. For a quick and dirty fix >> is very very amazing improvement. > > I like it too. seems safe enough tho I didn't test it directly. > > Raggi? What do you think? > > I think this (or equiv) is a mandatory change for 1.4 to go out. This is going to break parts of rubygems-test. I'd at least like to come up with an alternative solution that lets us use the on-installation testing features eventually. -Erik From erik at hollensbe.org Wed Dec 22 23:15:23 2010 From: erik at hollensbe.org (Erik Hollensbe) Date: Wed, 22 Dec 2010 23:15:23 -0500 Subject: [Rubygems-developers] Status of disabling plugins except for command line? In-Reply-To: <9950C8A3-D256-457D-BC69-BB20F2CEC35F@gmail.com> References: <9950C8A3-D256-457D-BC69-BB20F2CEC35F@gmail.com> Message-ID: <764BF705-FD2E-4297-88D2-A7D5B2FFC985@hollensbe.org> On Dec 22, 2010, at 10:46 PM, James Tucker wrote: > > - There have been no objections so far except from Erik Hollensbe, I think it's related to his recent gem testing plugin. We can provide hooks for him in a future version. This is actually working fine with Nutter's patch. No cause for alarm from me. -Erik From luislavena at gmail.com Thu Dec 23 11:15:14 2010 From: luislavena at gmail.com (Luis Lavena) Date: Thu, 23 Dec 2010 13:15:14 -0300 Subject: [Rubygems-developers] Status of disabling plugins except for command line? In-Reply-To: References: <8390C5FB-19BF-4ED5-A6E2-5B4FD58BEEC9@zenspider.com> Message-ID: On Wed, Dec 22, 2010 at 8:03 PM, Erik Hollensbe wrote: > > This is going to break parts of rubygems-test. I'd at least like to come up with an alternative solution that lets us use the on-installation testing features eventually. > How is that? I believe rubygems-test is a plugin that gets invoked by "gem install" or "gem test", so no break. We are disabling plugins for "require 'rubygems'" as it impacts on every single project that requires rubygems. -- 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 luislavena at gmail.com Thu Dec 23 11:17:23 2010 From: luislavena at gmail.com (Luis Lavena) Date: Thu, 23 Dec 2010 13:17:23 -0300 Subject: [Rubygems-developers] Status of disabling plugins except for command line? In-Reply-To: <764BF705-FD2E-4297-88D2-A7D5B2FFC985@hollensbe.org> References: <9950C8A3-D256-457D-BC69-BB20F2CEC35F@gmail.com> <764BF705-FD2E-4297-88D2-A7D5B2FFC985@hollensbe.org> Message-ID: On Thu, Dec 23, 2010 at 1:15 AM, Erik Hollensbe wrote: > > On Dec 22, 2010, at 10:46 PM, James Tucker wrote: >> >> - There have been no objections so far except from Erik Hollensbe, I think it's related to his recent gem testing plugin. We can provide hooks for him in a future version. > > This is actually working fine with Nutter's patch. No cause for alarm from me. > Wha? You just say it didn't : "This is going to break parts of rubygems-test. I'd at least like to come up with an alternative solution that lets us use the on-installation testing features eventually." http://rubyforge.org/pipermail/rubygems-developers/2010-December/005917.html -- 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 erik at hollensbe.org Thu Dec 23 11:22:18 2010 From: erik at hollensbe.org (Erik Hollensbe) Date: Thu, 23 Dec 2010 11:22:18 -0500 Subject: [Rubygems-developers] Status of disabling plugins except for command line? In-Reply-To: References: <9950C8A3-D256-457D-BC69-BB20F2CEC35F@gmail.com> <764BF705-FD2E-4297-88D2-A7D5B2FFC985@hollensbe.org> Message-ID: On Dec 23, 2010, at 11:17 AM, Luis Lavena wrote: > On Thu, Dec 23, 2010 at 1:15 AM, Erik Hollensbe wrote: >> >> On Dec 22, 2010, at 10:46 PM, James Tucker wrote: >>> >>> - There have been no objections so far except from Erik Hollensbe, I think it's related to his recent gem testing plugin. We can provide hooks for him in a future version. >> >> This is actually working fine with Nutter's patch. No cause for alarm from me. >> > > Wha? You just say it didn't : > > "This is going to break parts of rubygems-test. I'd at least like to > come up with an alternative solution that lets us use the > on-installation testing features eventually." > > http://rubyforge.org/pipermail/rubygems-developers/2010-December/005917.html Sorry; moderation is catching up with my posts; this is actually out of order. Final word on this subject: rubygems-test works fine with the upcoming version of rubygems. -Erik From jftucker at gmail.com Thu Dec 23 11:35:31 2010 From: jftucker at gmail.com (James Tucker) Date: Thu, 23 Dec 2010 11:35:31 -0500 Subject: [Rubygems-developers] Status of disabling plugins except for command line? In-Reply-To: References: <9950C8A3-D256-457D-BC69-BB20F2CEC35F@gmail.com> Message-ID: On Dec 23, 2010, at 4:08 AM, Trans wrote: > > > On Dec 22, 10:46 pm, James Tucker wrote: >> On Dec 22, 2010, at 5:56 PM, Charles Oliver Nutter wrote: >> >>> On Wed, Dec 22, 2010 at 1:33 PM, Charles Oliver Nutter >>> wrote: >>>> Here's my na?ve change and the impact to perf with around 500 installed gems: >> >>>> https://gist.github.com/751969 >> >>> I'm guessing there's also potential fixes for that scanning process, >>> all the way up to caching lists plugins on install (i.e. eliminating >>> future scans altogether), but this is a good quick fix for >>> non-command-line rubygems use. >> >> +1 on this patch for now. > > -1 _for now_. > >> - This will break 4 gem plugins, mostly minor and I've never seen them used 'in the wild'. I have the list knocking around somewhere, I'll dig it up if someone reminds me when I'm awake. > > I know of at least two gems it will break, and I suspect they are not > your four. Names please. I audited every single gem that is available on the rubygems.org index. A 61Gb expansion of all code. > I thought RubyGems was supposed to be so *conservative* about changes, > and here a change is just going to be pushed that breaks people's > plugins for the sake of a speed up for those who have 500+ gems > installed? This feature is currently broken. It's also not just effective for people with 500+ gems installed. This combined with changes that have already been merged into master brings rubygems.rb loading down to the same order of magnitude as gem_prelude.rb. My target is to have that buggy piece o' crap deprecated too. > Overlooking the fact that there other solutions to deal with large gem > collections, like rvm's gemsets. Why wouldn't the prudent course of > action be to actually fix this _correctly now_, rather than implement > a "phase 1" change that will leave certain types of plugins out in the > cold for who knows how long? Time. As stated, I've done my research, please name the gems that you claim will suffer. > If that's asking too much, then at the very least, make this patch a > configurable option in the .gemrc file. Power users who aren't using > any of the above mentioned plugins could then easily flip the switch > to get the speed up. Please explain this. From jftucker at gmail.com Thu Dec 23 11:38:59 2010 From: jftucker at gmail.com (James Tucker) Date: Thu, 23 Dec 2010 11:38:59 -0500 Subject: [Rubygems-developers] Status of disabling plugins except for command line? In-Reply-To: References: <9950C8A3-D256-457D-BC69-BB20F2CEC35F@gmail.com> Message-ID: <6BC72811-079D-4E79-8890-612E4B473988@gmail.com> On Dec 23, 2010, at 4:24 AM, Charles Oliver Nutter wrote: > On Thu, Dec 23, 2010 at 3:08 AM, Trans wrote: >> I know of at least two gems it will break, and I suspect they are not >> your four. > > You guys with your mystery lists. Spill it, man! https://gist.github.com/753222 this is the list I audited. Not sure where I left the list of those that were non-commands. From jftucker at gmail.com Thu Dec 23 11:39:32 2010 From: jftucker at gmail.com (James Tucker) Date: Thu, 23 Dec 2010 11:39:32 -0500 Subject: [Rubygems-developers] Status of disabling plugins except for command line? In-Reply-To: References: <9950C8A3-D256-457D-BC69-BB20F2CEC35F@gmail.com> Message-ID: <05F6461B-551B-4E8B-83C5-F6B98DF47689@gmail.com> On Dec 23, 2010, at 5:42 AM, Charles Oliver Nutter wrote: > FYI, Eric Hollensbe pinged me on Twitter to say that this change does > not appear to break his gem. So that's at least one confirmed ok. Awesome, +2 then. > He also said his messages keep getting moderated into oblivion. > Someone might want to see to that. Fixed. From jftucker at gmail.com Thu Dec 23 11:48:50 2010 From: jftucker at gmail.com (James Tucker) Date: Thu, 23 Dec 2010 11:48:50 -0500 Subject: [Rubygems-developers] Status of disabling plugins except for command line? In-Reply-To: References: <9950C8A3-D256-457D-BC69-BB20F2CEC35F@gmail.com> Message-ID: <1FC4CAFC-AD9B-47B7-A001-E8479042A9E1@gmail.com> On Dec 23, 2010, at 10:55 AM, Trans wrote: > > > On Dec 23, 4:24 am, Charles Oliver Nutter wrote: >> On Thu, Dec 23, 2010 at 3:08 AM, Trans wrote: >>> I know of at least two gems it will break, and I suspect they are not >>> your four. >> >> You guys with your mystery lists. Spill it, man! > > The two I know of are gem-wedge and ore. > > Ore is especially ironic, b/c I was recently told that RubyGems did > not need to support plain YAML specs itself b/c a plugin, like Ore, > could do the job. Ore doesn't contain a rubygems_plugin.rb. Dude, come on. When I looked at wedge, I figured it was largely experimental and not widely used. It's hooks can also be installed elsehow (that is, by having the application load it - the same way bundler and isolate do). If you want to avoid that, you could add -rwedge to RUBYOPT. >>> I thought RubyGems was supposed to be so *conservative* about changes, >>> and here a change is just going to be pushed that breaks people's >>> plugins for the sake of a speed up for those who have 500+ gems >>> installed? >> >> It's not just a problem for 500+, it's a problem for anyone who >> installs, say, Rails 3's several dozen dependencies. Globbing through >> all those directories gets linearly slower, and even people with just >> a few gems will notice a startup improvement from this. >> >> The right answer is that plugins should NEVER have been >> auto-discovered with a filesystem scan on every startup since that's >> inherently O(N) as more gems are introduced (and especially bad on >> implementations that already have startup concerns like JRuby or >> Rubinius). > > Doesn't the file system itself cache the file access, so after the > first run it speeds up for every subsequent use? So it's not quite > that bad. But to be sure I am not against fixing this, I just don't > want to see non-command plugins broken to do it. No, because the search loads the entire source index and scans through it in ruby space. >> So I feel more like we're righting an over-eager change >> (plugins scanned on every load of 'rubygems') by backing off the most >> egregious aspect of that decision. We're not breaking good behavior, >> we're rolling back bad behavior. I call that a bug fix. > > One man's bug is another man's feature ;) Actually, I've seen more bug reports from broken plugins forcing people to manually remove gems and/or reinstall everything than I have seen usage of non-command plugins. Bear in mind that I've been both following the tracker, and diving through /all gems/ as my research. >>> Overlooking the fact that there other solutions to deal with large gem >>> collections, like rvm's gemsets. Why wouldn't the prudent course of >>> action be to actually fix this _correctly now_, rather than implement >>> a "phase 1" change that will leave certain types of plugins out in the >>> cold for who knows how long? >> >>> If that's asking too much, then at the very least, make this patch a >>> configurable option in the .gemrc file. Power users who aren't using >>> any of the above mentioned plugins could then easily flip the switch >>> to get the speed up. >> >> No plugins have been mentioned :) All I see are shadows and spectres. >> >> I want to know what these plugins are and why this change breaks them. >> If there's additional changes required to keep them working, we can >> discuss that. But having a simple load of 'rubygems' scan the >> filesystem every freaking time is a nonstarter (and should always have >> been). > > No, it was a shortcut then, and now another shortcut is being made to > remedy the first. > > A real solution would check for a plugins at install time, if one is > found copy it to a special location, e.g. gems/plugins, in much the > same way that a gem's specification is copied to a special location. > Then when Rubygems is loaded there is no need to search the file > system, all the plugins are in one place. That's actually not quite enough. These problems have nasty edge cases: Many plugins use File.expand_path to load their other parts, because we don't activate plugins. We should not be loading multiple versions of a single plugin. What should be the policy when a newer gem is installed that does not contain a plugin, but an older version does contain a plugin? This can lead to unresolvable problems. We need options to turn the features off in future. This is all in my long term plan. We're not alienating anyone by this change, and people have been trying it out in the wild for a good deal of time too, as well as I've been watching and researching it. From transfire at gmail.com Thu Dec 23 13:21:15 2010 From: transfire at gmail.com (Trans) Date: Thu, 23 Dec 2010 10:21:15 -0800 (PST) Subject: [Rubygems-developers] Status of disabling plugins except for command line? In-Reply-To: <1FC4CAFC-AD9B-47B7-A001-E8479042A9E1@gmail.com> References: <9950C8A3-D256-457D-BC69-BB20F2CEC35F@gmail.com> <1FC4CAFC-AD9B-47B7-A001-E8479042A9E1@gmail.com> Message-ID: On Dec 23, 11:48?am, James Tucker wrote: > Ore doesn't contain a rubygems_plugin.rb. Dude, come on. http://github.com/ruby-ore/ore-core/tree/master/lib I am not sure how postmodern utilizes this, and there may be a work around here too, but nonetheless it's not a "spectre" ;) > When I looked at wedge, I figured it was largely experimental and not widely used. It's hooks can also be installed elsehow (that is, by having the application load it - the same way bundler and isolate do). If you want to avoid that, you could add -rwedge to RUBYOPT. Hmm.. it's not really a per-application kind of thing, but the later idea might work.... well yea obviously b/c then we're basically setting up an explicit plugin for Ruby itself. Maybe not as convenient as the gem plugin, but perhaps better for being more explicit. I'll play around with that and see how it goes, thanks. > Actually, I've seen more bug reports from broken plugins forcing people to manually remove gems and/or reinstall everything than I have seen usage of non-command plugins. Bear in mind that I've been both following the tracker, and diving through /all gems/ as my research. Reinstall everything? How would a plugin cause that? Eek. In any case, I would think command plugins are just as prone to error as any plugin. > > A real solution would check for a plugins at install time, if one is > > found copy it to a special location, e.g. gems/plugins, in much the > > same way that a gem's specification is copied to a special location. > > Then when Rubygems is loaded there is no need to search the file > > system, all the plugins are in one place. > > That's actually not quite enough. These problems have nasty edge cases: > > Many plugins use File.expand_path to load their other parts, because we don't activate plugins. > We should not be loading multiple versions of a single plugin. > What should be the policy when a newer gem is installed that does not contain a plugin, but an older version does contain a plugin? This can lead to unresolvable problems. > We need options to turn the features off in future. > > This is all in my long term plan. We're not alienating anyone by this change, and people have been trying it out in the wild for a good deal of time too, as well as I've been watching and researching it. Yep, I understand on all accounts. Just would be nice to go head and do the long term plan and get it done. Things may not be prefect as is, but we've been working with it as is for a while now and getting by. Recently I was toying with the idea of extend Bundler's Gemfile. But Bundler has no plugin system, so I wasn't sure how I could make it work. Then I realized I could use rubygems plugin system b/c Bundler depends on Rubygems. I tried it and it worked fine. This was just experimental, as I said, but I think it's a good example of possibilities that might be limited. From transfire at gmail.com Thu Dec 23 13:32:17 2010 From: transfire at gmail.com (Trans) Date: Thu, 23 Dec 2010 10:32:17 -0800 (PST) Subject: [Rubygems-developers] Status of disabling plugins except for command line? In-Reply-To: References: <9950C8A3-D256-457D-BC69-BB20F2CEC35F@gmail.com> Message-ID: <917582f1-4b87-4f53-bd40-260591aa8e25@k11g2000vbf.googlegroups.com> On Dec 23, 11:35?am, James Tucker wrote: > > If that's asking too much, then at the very least, make this patch a > > configurable option in the .gemrc file. Power users who aren't using > > any of the above mentioned plugins could then easily flip the switch > > to get the speed up. > > Please explain this. Basically something like... rubygems/config_file.rb # True if we want plugin loading to be limited to gem command attr :command_plugins_only rubygems.rb unless Gem.configuration.command_plugins_only gem.load_plugins end rubygems/gem_runner.rb if Gem.configuration.command_plugins_only gem.load_plugins end From headius at headius.com Thu Dec 23 14:00:40 2010 From: headius at headius.com (Charles Oliver Nutter) Date: Thu, 23 Dec 2010 13:00:40 -0600 Subject: [Rubygems-developers] Status of disabling plugins except for command line? In-Reply-To: References: <9950C8A3-D256-457D-BC69-BB20F2CEC35F@gmail.com> Message-ID: On Thu, Dec 23, 2010 at 9:55 AM, Trans wrote: > On Dec 23, 4:24?am, Charles Oliver Nutter wrote: > The two I know of are gem-wedge and ore. > > Ore is especially ironic, b/c I was recently told that RubyGems did > not need to support plain YAML specs itself b/c a plugin, like Ore, > could do the job. How does this break them? > Doesn't the file system itself cache the file access, so after the > first run it speeds up for every subsequent use? So it's not quite > that bad. But to be sure I am not against fixing this, I just don't > want to see non-command plugins broken to do it. Yes it does. With 500+ gems the uncached startup time on JRuby was 17 seconds. Cached time went down to 6.9. Without plugin scanning, under half a second. I consider that pretty bad, even cached. > A real solution would check for a plugins at install time, if one is > found copy it to a special location, e.g. gems/plugins, in much the > same way that a gem's specification is copied to a special location. > Then when Rubygems is loaded there is no need to search the file > system, all the plugins are in one place. Agreed. That doesn't seem like something that can land in the short term. This is a very clean, very light patch for a magnificent improvement, at the cost of a handful of plugins. And depending on how they break, the workaround could simply be to require 'gem_runner' (or to create a new "plugins.rb" with the plugin-loading logic, and then the workaround is to require that). - Charlie From jftucker at gmail.com Thu Dec 23 14:14:24 2010 From: jftucker at gmail.com (James Tucker) Date: Thu, 23 Dec 2010 14:14:24 -0500 Subject: [Rubygems-developers] Status of disabling plugins except for command line? In-Reply-To: References: <9950C8A3-D256-457D-BC69-BB20F2CEC35F@gmail.com> <1FC4CAFC-AD9B-47B7-A001-E8479042A9E1@gmail.com> Message-ID: <904580CA-5C61-4159-958D-67E3830FF5E9@gmail.com> On Dec 23, 2010, at 1:21 PM, Trans wrote: > On Dec 23, 11:48 am, James Tucker wrote: >> Ore doesn't contain a rubygems_plugin.rb. Dude, come on. > > http://github.com/ruby-ore/ore-core/tree/master/lib > > I am not sure how postmodern utilizes this, and there may be a work > around here too, but nonetheless it's not a "spectre" ;) I looked in the wrong repo. My bad. This code doesn't seem to modify rubygems at all, and doesn't need to be a rubygems plugin as far as I can see. >> When I looked at wedge, I figured it was largely experimental and not widely used. It's hooks can also be installed elsehow (that is, by having the application load it - the same way bundler and isolate do). If you want to avoid that, you could add -rwedge to RUBYOPT. > > Hmm.. it's not really a per-application kind of thing, but the later > idea might work.... well yea obviously b/c then we're basically > setting up an explicit plugin for Ruby itself. Maybe not as convenient > as the gem plugin, but perhaps better for being more explicit. I'll > play around with that and see how it goes, thanks. I do later want to add hooks for the rest of this, but that'll be as time allows. >> Actually, I've seen more bug reports from broken plugins forcing people to manually remove gems and/or reinstall everything than I have seen usage of non-command plugins. Bear in mind that I've been both following the tracker, and diving through /all gems/ as my research. > > Reinstall everything? How would a plugin cause that? Eek. In any case, > I would think command plugins are just as prone to error as any > plugin. raise 'boom' in rubygems_plugin.rb Real world cases of this came up with older versions of gemcutter plugins. Many users don't know how to manually uninstall gems, so their response (when they can't find help) is to reinstall their ruby + rubygems. >>> A real solution would check for a plugins at install time, if one is >>> found copy it to a special location, e.g. gems/plugins, in much the >>> same way that a gem's specification is copied to a special location. >>> Then when Rubygems is loaded there is no need to search the file >>> system, all the plugins are in one place. >> >> That's actually not quite enough. These problems have nasty edge cases: >> >> Many plugins use File.expand_path to load their other parts, because we don't activate plugins. >> We should not be loading multiple versions of a single plugin. >> What should be the policy when a newer gem is installed that does not contain a plugin, but an older version does contain a plugin? This can lead to unresolvable problems. >> We need options to turn the features off in future. >> >> This is all in my long term plan. We're not alienating anyone by this change, and people have been trying it out in the wild for a good deal of time too, as well as I've been watching and researching it. > > Yep, I understand on all accounts. Just would be nice to go head and > do the long term plan and get it done. Things may not be prefect as > is, but we've been working with it as is for a while now and getting > by. Agreed, that would be nice, I've just run out of time, and people have been asking me for months now. I think it's fair to go with the commonly made demands and fix common problems, than to wait for my time to become available. The balance tips toward those folks with problems, which are more numerous than those we affect, especially in light of available workarounds. > Recently I was toying with the idea of extend Bundler's Gemfile. But > Bundler has no plugin system, so I wasn't sure how I could make it > work. Then I realized I could use rubygems plugin system b/c Bundler > depends on Rubygems. I tried it and it worked fine. This was just > experimental, as I said, but I think it's a good example of > possibilities that might be limited. The Gemfile is an instance_eval. You can extend it like so: require 'my_extension' extend MyExtension Among other ways. From jftucker at gmail.com Thu Dec 23 14:18:09 2010 From: jftucker at gmail.com (James Tucker) Date: Thu, 23 Dec 2010 14:18:09 -0500 Subject: [Rubygems-developers] Status of disabling plugins except for command line? In-Reply-To: <917582f1-4b87-4f53-bd40-260591aa8e25@k11g2000vbf.googlegroups.com> References: <9950C8A3-D256-457D-BC69-BB20F2CEC35F@gmail.com> <917582f1-4b87-4f53-bd40-260591aa8e25@k11g2000vbf.googlegroups.com> Message-ID: <13A5885A-8D15-480D-8296-467FEA7E1CB0@gmail.com> On Dec 23, 2010, at 1:32 PM, Trans wrote: > > > On Dec 23, 11:35 am, James Tucker wrote: > >>> If that's asking too much, then at the very least, make this patch a >>> configurable option in the .gemrc file. Power users who aren't using >>> any of the above mentioned plugins could then easily flip the switch >>> to get the speed up. >> >> Please explain this. > > Basically something like... I meant something more along the lines of why do we consider power users as needing the speed up. Everyone needs the speed up, my eventual target is to have gem_prelude.rb deprecated and to get rubygems.rb up to that speed. "Power users" are the 10 or so people that use non-command based plugins. They should easily be able to do whatever to gain speed, typical things are to preload the source_index and then run GC.start (on MRI) as this reduces memory fragmentation. You can also rewrite your source index to use symbols to further save on ram costs, etc. That's not really what this patch is about though. This patch is about fixing an order of magnitude inefficiency that's barely used that affects everyone. All I mean is, the default should be to not load plugins, until we have a non-edgy plugin index and some better plugin hooks that can work with single-activations. > rubygems/config_file.rb > > # True if we want plugin loading to be limited to gem command > attr :command_plugins_only > > rubygems.rb > > unless Gem.configuration.command_plugins_only > gem.load_plugins > end > > rubygems/gem_runner.rb > > if Gem.configuration.command_plugins_only > gem.load_plugins > end > > _______________________________________________ > Rubygems-developers mailing list > http://rubyforge.org/projects/rubygems > Rubygems-developers at rubyforge.org > http://rubyforge.org/mailman/listinfo/rubygems-developers From headius at headius.com Thu Dec 23 14:22:07 2010 From: headius at headius.com (Charles Oliver Nutter) Date: Thu, 23 Dec 2010 13:22:07 -0600 Subject: [Rubygems-developers] Status of disabling plugins except for command line? In-Reply-To: <917582f1-4b87-4f53-bd40-260591aa8e25@k11g2000vbf.googlegroups.com> References: <9950C8A3-D256-457D-BC69-BB20F2CEC35F@gmail.com> <917582f1-4b87-4f53-bd40-260591aa8e25@k11g2000vbf.googlegroups.com> Message-ID: On Thu, Dec 23, 2010 at 12:32 PM, Trans wrote: > Basically something like... > > rubygems/config_file.rb > > ?# True if we want plugin loading to be limited to gem command > ?attr :command_plugins_only > > rubygems.rb > > ?unless Gem.configuration.command_plugins_only > ? ?gem.load_plugins > ?end > > rubygems/gem_runner.rb > > ?if Gem.configuration.command_plugins_only > ? ?gem.load_plugins > ?end I also mocked up something like this in JRuby's repo (long since lost now). I wouldn't be opposed to having a .gemrc or ENV var to turn global plugin loading back on. It would be a cleaner workaround than RUBYOPT requires of specific RubyGems files. I don't think global plugin loading should be the norm, though, until it doesn't incur a massive perf hit. - Charlie From jftucker at gmail.com Thu Dec 23 15:08:01 2010 From: jftucker at gmail.com (James Tucker) Date: Thu, 23 Dec 2010 15:08:01 -0500 Subject: [Rubygems-developers] Status of disabling plugins except for command line? In-Reply-To: References: <9950C8A3-D256-457D-BC69-BB20F2CEC35F@gmail.com> <917582f1-4b87-4f53-bd40-260591aa8e25@k11g2000vbf.googlegroups.com> Message-ID: <02776633-6E77-4004-842C-AF53E4A9B364@gmail.com> On Dec 23, 2010, at 2:22 PM, Charles Oliver Nutter wrote: > > I also mocked up something like this in JRuby's repo (long since lost > now). I wouldn't be opposed to having a .gemrc or ENV var to turn > global plugin loading back on. It would be a cleaner workaround than > RUBYOPT requires of specific RubyGems files. Agreed. > I don't think global plugin loading should be the norm, though, until > it doesn't incur a massive perf hit. Agreed. From drbrain at segment7.net Thu Dec 23 15:33:27 2010 From: drbrain at segment7.net (Eric Hodel) Date: Thu, 23 Dec 2010 12:33:27 -0800 Subject: [Rubygems-developers] Status of disabling plugins except for command line? In-Reply-To: References: <9950C8A3-D256-457D-BC69-BB20F2CEC35F@gmail.com> Message-ID: On Dec 23, 2010, at 01:08, Trans wrote: > I thought RubyGems was supposed to be so *conservative* about changes, > and here a change is just going to be pushed that breaks people's > plugins for the sake of a speed up for those who have 500+ gems > installed? I thought adding plugins this way would be conservative. It turns out I was mistaken. We're fixing a performance bug. > Overlooking the fact that there other solutions to deal with large gem > collections, like rvm's gemsets. Why wouldn't the prudent course of > action be to actually fix this _correctly now_, rather than implement > a "phase 1" change that will leave certain types of plugins out in the > cold for who knows how long? Shortly after I added scanning for rubygems_plugins.rb I found it was the incorrect solution as it is not granular. > If that's asking too much, then at the very least, make this patch a > configurable option in the .gemrc file. Power users who aren't using > any of the above mentioned plugins could then easily flip the switch > to get the speed up. We should make a release that contains this change RubyGems 2.0 as this changes an API. From drbrain at segment7.net Thu Dec 23 15:46:04 2010 From: drbrain at segment7.net (Eric Hodel) Date: Thu, 23 Dec 2010 12:46:04 -0800 Subject: [Rubygems-developers] Status of disabling plugins except for command line? In-Reply-To: References: <9950C8A3-D256-457D-BC69-BB20F2CEC35F@gmail.com> <917582f1-4b87-4f53-bd40-260591aa8e25@k11g2000vbf.googlegroups.com> Message-ID: On Dec 23, 2010, at 11:22, Charles Oliver Nutter wrote: > I don't think global plugin loading should be the norm, though, until > it doesn't incur a massive perf hit. I don't think it should ever be re-enabled. It was a bad mistake that a more thoughtful implementation (load plugins when necessar) would have avoided. rubygems/install_plugin.rb - loaded when the installer is required rubygems/command_plugin.rb - loaded when the command manager is required etc. We won't need global plugins if we have appropriate hooks like these. From headius at headius.com Thu Dec 23 16:55:16 2010 From: headius at headius.com (Charles Oliver Nutter) Date: Thu, 23 Dec 2010 15:55:16 -0600 Subject: [Rubygems-developers] Status of disabling plugins except for command line? In-Reply-To: References: <9950C8A3-D256-457D-BC69-BB20F2CEC35F@gmail.com> Message-ID: On Thu, Dec 23, 2010 at 2:33 PM, Eric Hodel wrote: > We should make a release that contains this change RubyGems 2.0 as this changes an API. To clarify, you are saying 1.4 should include the perf "fix" (moving plugin loading to gem_runner) and 2.0 should include an option to force it to always scan plugins? - Charlie From drbrain at segment7.net Thu Dec 23 18:08:12 2010 From: drbrain at segment7.net (Eric Hodel) Date: Thu, 23 Dec 2010 15:08:12 -0800 Subject: [Rubygems-developers] Status of disabling plugins except for command line? In-Reply-To: References: <9950C8A3-D256-457D-BC69-BB20F2CEC35F@gmail.com> Message-ID: On Dec 23, 2010, at 13:55, Charles Oliver Nutter wrote: > On Thu, Dec 23, 2010 at 2:33 PM, Eric Hodel wrote: >> We should make a release that contains this change RubyGems 2.0 as this changes an API. > > To clarify, you are saying 1.4 should include the perf "fix" (moving > plugin loading to gem_runner) and 2.0 should include an option to > force it to always scan plugins? We should not release a 1.4 with the perf fix as it incompatibly changes an API. Releasing a 1.4 with the perf fix is not in line with RubyGems own versioning recommendations (which I should have been following all the way back to 1.0). I think 2.0 should be released with the perf fix and more granular plugins. I can implement granular plugins in a couple days, and I should have some free time to do so next week. From transfire at gmail.com Thu Dec 23 18:12:27 2010 From: transfire at gmail.com (Trans) Date: Thu, 23 Dec 2010 15:12:27 -0800 (PST) Subject: [Rubygems-developers] Status of disabling plugins except for command line? In-Reply-To: References: <9950C8A3-D256-457D-BC69-BB20F2CEC35F@gmail.com> Message-ID: <012ef712-781b-495c-8846-c8a5074237da@s4g2000yql.googlegroups.com> On Dec 23, 3:33?pm, Eric Hodel wrote: > > If that's asking too much, then at the very least, make this patch a > > configurable option in the .gemrc file. Power users who aren't using > > any of the above mentioned plugins could then easily flip the switch > > to get the speed up. > > We should make a release that contains this change RubyGems 2.0 as this changes an API. Not sure what that accomplishes. The usefulness of the pref switch is backward compatibility. When someone (who is unaware of all this) comes along complaining that his plugin stopped working, you can tell him to active the pref switch; problem solved. Changing the config_file API shouldn't break anything. I've tested out adding arbitrary garbage entries to the .gemrc file and it appears to work fine. I would hope by 2.0, a new plugin system would be in place addressing all the issues noted by James. From drbrain at segment7.net Thu Dec 23 18:26:46 2010 From: drbrain at segment7.net (Eric Hodel) Date: Thu, 23 Dec 2010 15:26:46 -0800 Subject: [Rubygems-developers] Status of disabling plugins except for command line? In-Reply-To: <012ef712-781b-495c-8846-c8a5074237da@s4g2000yql.googlegroups.com> References: <9950C8A3-D256-457D-BC69-BB20F2CEC35F@gmail.com> <012ef712-781b-495c-8846-c8a5074237da@s4g2000yql.googlegroups.com> Message-ID: <23E62651-FAD9-47AF-A59F-3EBF50417CFE@segment7.net> On Dec 23, 2010, at 15:12, Trans wrote: > On Dec 23, 3:33 pm, Eric Hodel wrote: >>> If that's asking too much, then at the very least, make this patch a >>> configurable option in the .gemrc file. Power users who aren't using >>> any of the above mentioned plugins could then easily flip the switch >>> to get the speed up. >> >> We should make a release that contains this change RubyGems 2.0 as this changes an API. > > Not sure what that accomplishes. The usefulness of the pref switch is > backward compatibility. RubyGems should not support mistakes. > When someone (who is unaware of all this) > comes along complaining that his plugin stopped working, you can tell > him to active the pref switch; problem solved. You mean two people. We can just email them instead. From headius at headius.com Thu Dec 23 18:48:21 2010 From: headius at headius.com (Charles Oliver Nutter) Date: Thu, 23 Dec 2010 17:48:21 -0600 Subject: [Rubygems-developers] Status of disabling plugins except for command line? In-Reply-To: References: <9950C8A3-D256-457D-BC69-BB20F2CEC35F@gmail.com> Message-ID: On Thu, Dec 23, 2010 at 5:08 PM, Eric Hodel wrote: > We should not release a 1.4 with the perf fix as it incompatibly changes an API. ?Releasing a 1.4 with the perf fix is not in line with RubyGems own versioning recommendations (which I should have been following all the way back to 1.0). > > I think 2.0 should be released with the perf fix and more granular plugins. ?I can implement granular plugins in a couple days, and I should have some free time to do so next week. What sort of timeframe are we talking about for 2.0? Because of the large improvement this fix provides, I almost have a mind to ship it in JRuby anyway...we take a lot of flak for that startup hit. - Charlie From drbrain at segment7.net Thu Dec 23 19:08:40 2010 From: drbrain at segment7.net (Eric Hodel) Date: Thu, 23 Dec 2010 16:08:40 -0800 Subject: [Rubygems-developers] Status of disabling plugins except for command line? In-Reply-To: References: <9950C8A3-D256-457D-BC69-BB20F2CEC35F@gmail.com> Message-ID: On Dec 23, 2010, at 15:48, Charles Oliver Nutter wrote: > On Thu, Dec 23, 2010 at 5:08 PM, Eric Hodel wrote: >> We should not release a 1.4 with the perf fix as it incompatibly changes an API. Releasing a 1.4 with the perf fix is not in line with RubyGems own versioning recommendations (which I should have been following all the way back to 1.0). >> >> I think 2.0 should be released with the perf fix and more granular plugins. I can implement granular plugins in a couple days, and I should have some free time to do so next week. > > What sort of timeframe are we talking about for 2.0? Because of the > large improvement this fix provides, I almost have a mind to ship it > in JRuby anyway...we take a lot of flak for that startup hit. I think the next release should be 2.0? what's now on 1.4 branch plus whatever else we pull into it. From headius at headius.com Fri Dec 24 02:21:26 2010 From: headius at headius.com (Charles Oliver Nutter) Date: Fri, 24 Dec 2010 01:21:26 -0600 Subject: [Rubygems-developers] Status of disabling plugins except for command line? In-Reply-To: References: <9950C8A3-D256-457D-BC69-BB20F2CEC35F@gmail.com> Message-ID: On Thu, Dec 23, 2010 at 6:08 PM, Eric Hodel wrote: > I think the next release should be 2.0? what's now on 1.4 branch plus whatever else we pull into it. Sounds good to me. - Charlie From luislavena at gmail.com Mon Dec 27 10:10:05 2010 From: luislavena at gmail.com (Luis Lavena) Date: Mon, 27 Dec 2010 12:10:05 -0300 Subject: [Rubygems-developers] download-reporter branch for review Message-ID: Hello, I've reimplemented the original proposal from Ryan Melt: https://github.com/rubygems/rubygems/pull/2 Into 'download-reporter' branch: https://github.com/rubygems/rubygems/tree/download-reporter Basically I've created a SilentDownloadReporter and VerboseDownloadReporter to mimic *ProgressReporter. I've also made it non-tty friendly, so deployment logs do not generate lot of noise due redirections. To see how it looks like, I've created the following gists: https://gist.github.com/756192 Above shows download reports for every single HTTP download RubyGems does, and that could be noisy (see all the fetching of gemspecs on a clean home) This one: https://gist.github.com/756198 Only display the reporter for .gem files, less noisy but there is still some "silence" before due the gemspec fetching. If nobody objects, will merge it into master. Looking forward for your comments and suggestions. Perhaps the API can be cleaned up. Thank you for your time. -- 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 transfire at gmail.com Tue Dec 28 11:28:06 2010 From: transfire at gmail.com (Trans) Date: Tue, 28 Dec 2010 08:28:06 -0800 (PST) Subject: [Rubygems-developers] Status of disabling plugins except for command line? In-Reply-To: <23E62651-FAD9-47AF-A59F-3EBF50417CFE@segment7.net> References: <9950C8A3-D256-457D-BC69-BB20F2CEC35F@gmail.com> <012ef712-781b-495c-8846-c8a5074237da@s4g2000yql.googlegroups.com> <23E62651-FAD9-47AF-A59F-3EBF50417CFE@segment7.net> Message-ID: <90e9448f-9636-4ac5-8963-fb80f1148f91@s5g2000yqm.googlegroups.com> On Dec 23, 6:26?pm, Eric Hodel wrote: > On Dec 23, 2010, at 15:12, Trans wrote: > > > On Dec 23, 3:33 pm, Eric Hodel wrote: > >>> If that's asking too much, then at the very least, make this patch a > >>> configurable option in the .gemrc file. Power users who aren't using > >>> any of the above mentioned plugins could then easily flip the switch > >>> to get the speed up. > > >> We should make a release that contains this change RubyGems 2.0 as this changes an API. > > > Not sure what that accomplishes. The usefulness of the pref switch is > > backward compatibility. > > RubyGems should not support mistakes. If all you want is gem command plugins, then why not just route `gem foo` to `gem-foo`? Then there would be zero lookup overhead. From jftucker at gmail.com Tue Dec 28 12:27:46 2010 From: jftucker at gmail.com (James Tucker) Date: Tue, 28 Dec 2010 12:27:46 -0500 Subject: [Rubygems-developers] Status of disabling plugins except for command line? In-Reply-To: <90e9448f-9636-4ac5-8963-fb80f1148f91@s5g2000yqm.googlegroups.com> References: <9950C8A3-D256-457D-BC69-BB20F2CEC35F@gmail.com> <012ef712-781b-495c-8846-c8a5074237da@s4g2000yql.googlegroups.com> <23E62651-FAD9-47AF-A59F-3EBF50417CFE@segment7.net> <90e9448f-9636-4ac5-8963-fb80f1148f91@s5g2000yqm.googlegroups.com> Message-ID: <51239EDF-72FB-487E-9844-E47BA9FDCC5F@gmail.com> On Dec 28, 2010, at 11:28 AM, Trans wrote: > > > On Dec 23, 6:26 pm, Eric Hodel wrote: >> On Dec 23, 2010, at 15:12, Trans wrote: >> >>> On Dec 23, 3:33 pm, Eric Hodel wrote: >>>>> If that's asking too much, then at the very least, make this patch a >>>>> configurable option in the .gemrc file. Power users who aren't using >>>>> any of the above mentioned plugins could then easily flip the switch >>>>> to get the speed up. >> >>>> We should make a release that contains this change RubyGems 2.0 as this changes an API. >> >>> Not sure what that accomplishes. The usefulness of the pref switch is >>> backward compatibility. >> >> RubyGems should not support mistakes. > > If all you want is gem command plugins, then why not just route `gem > foo` to `gem-foo`? Then there would be zero lookup overhead. That's not the only use case. > _______________________________________________ > 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 Tue Dec 28 20:26:15 2010 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 28 Dec 2010 20:26:15 -0500 (EST) Subject: [Rubygems-developers] [ rubygems-Bugs-28806 ] Re-install of a gem can leave prior gem files remaining Message-ID: <20101229012615.C42F7167831C@rubyforge.org> Bugs item #28806, was opened at 2010-12-28 17:26 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28806&group_id=126 Category: `gem install` command Group: None Status: Open Resolution: None Priority: 3 Submitted By: David Kellum (dekellum) Assigned to: Nobody (None) Summary: Re-install of a gem can leave prior gem files remaining Initial Comment: The problem arises when the contents of gem change over multiple builds with the same gem version, typically when a gem is under development and installed repeatedly to a local gem home. There are several cases where gems load or otherwise use all files in a particular directory within the gem install dir. When a file is removed or renamed over subsequent builds, old files from the prior "gem install" will remain after the new "gem install", leading to often unexpected behavior. One specific example would be gem packaged ActiveRecord migrations directory, where all migrations in a gem installed "db/" directory are applied. To avoid any chance of inconsistent behavior from prior installed gem files, it would be best if the gem Installer removed all old files from the gem_dir before installing the new files. It looks like an easy change. I will offer a patch for this issue up on github. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28806&group_id=126 From noreply at rubyforge.org Tue Dec 28 20:35:58 2010 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 28 Dec 2010 20:35:58 -0500 (EST) Subject: [Rubygems-developers] [ rubygems-Bugs-28806 ] Re-install of a gem can leave prior gem files remaining Message-ID: <20101229013558.3ADE01858300@rubyforge.org> Bugs item #28806, was opened at 2010-12-28 17:26 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28806&group_id=126 Category: `gem install` command Group: None Status: Open Resolution: None Priority: 3 Submitted By: David Kellum (dekellum) Assigned to: Nobody (None) Summary: Re-install of a gem can leave prior gem files remaining Initial Comment: The problem arises when the contents of gem change over multiple builds with the same gem version, typically when a gem is under development and installed repeatedly to a local gem home. There are several cases where gems load or otherwise use all files in a particular directory within the gem install dir. When a file is removed or renamed over subsequent builds, old files from the prior "gem install" will remain after the new "gem install", leading to often unexpected behavior. One specific example would be gem packaged ActiveRecord migrations directory, where all migrations in a gem installed "db/" directory are applied. To avoid any chance of inconsistent behavior from prior installed gem files, it would be best if the gem Installer removed all old files from the gem_dir before installing the new files. It looks like an easy change. I will offer a patch for this issue up on github. ---------------------------------------------------------------------- >Comment By: David Kellum (dekellum) Date: 2010-12-28 17:35 Message: Pull request: https://github.com/rubygems/rubygems/pull/18 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28806&group_id=126 From drbrain at segment7.net Wed Dec 29 04:51:20 2010 From: drbrain at segment7.net (Eric Hodel) Date: Wed, 29 Dec 2010 01:51:20 -0800 Subject: [Rubygems-developers] download-reporter branch for review In-Reply-To: References: Message-ID: <349D741A-F6DD-494A-9B88-16C81F4C6659@segment7.net> On Dec 27, 2010, at 07:10, Luis Lavena wrote: > Hello, > > I've reimplemented the original proposal from Ryan Melt: > > https://github.com/rubygems/rubygems/pull/2 > > Into 'download-reporter' branch: > > https://github.com/rubygems/rubygems/tree/download-reporter > > Basically I've created a SilentDownloadReporter and > VerboseDownloadReporter to mimic *ProgressReporter. > > I've also made it non-tty friendly, so deployment logs do not generate > lot of noise due redirections. Typo in lib/rubygems/remote_fetcher.rb: incomplete_respose Please indent 'private' in class VerboseDownloadReporter in lib/rubygems/user_interaction.rb to the same level as def. > If nobody objects, will merge it into master. > > Looking forward for your comments and suggestions. Perhaps the API can > be cleaned up. We trust your work. In the future, Just Do It? ? From ryand-ruby at zenspider.com Wed Dec 29 05:13:56 2010 From: ryand-ruby at zenspider.com (Ryan Davis) Date: Wed, 29 Dec 2010 02:13:56 -0800 Subject: [Rubygems-developers] download-reporter branch for review In-Reply-To: <349D741A-F6DD-494A-9B88-16C81F4C6659@segment7.net> References: <349D741A-F6DD-494A-9B88-16C81F4C6659@segment7.net> Message-ID: On Dec 29, 2010, at 01:51 , Eric Hodel wrote: >> If nobody objects, will merge it into master. >> >> Looking forward for your comments and suggestions. Perhaps the API can >> be cleaned up. > > We trust your work. In the future, Just Do It? ? seconded. stop asking pls From ryand-ruby at zenspider.com Wed Dec 29 05:20:36 2010 From: ryand-ruby at zenspider.com (Ryan Davis) Date: Wed, 29 Dec 2010 02:20:36 -0800 Subject: [Rubygems-developers] CI Status (was: RubyGemsGitHub build 1e71d86 failed) In-Reply-To: References: Message-ID: On Dec 21, 2010, at 13:16 , Ryan Davis wrote: > > On Dec 13, 2010, at 22:52 , Chad Woolley wrote: > >> On Mon, Dec 13, 2010 at 9:17 PM, Chad Woolley wrote: >>> I've got a working pass at a dynamic multi-interpreter build here (and >>> it's green under 1.8.7): >>> >>> http://cibuilder.pivotallabs.com:3333/builds/RubyGems-1_8_7-p302 > > This is the latest version of 1.8.7 and runs clean. > > I dunno if you have control over this, but not having good titles on the HTML page makes distinguishing tabs a PITA. > >> http://cibuilder.pivotallabs.com:3333/builds/RubyGems-1_9_1-p429 > > p430 is the latest release on 1.9.1. > > This fails: > >> rake aborted! >> no such file to load -- hoe >> >> /home/pivotal/.cruise/projects/RubyGems-1_9_1-p429/work/Rakefile:8 >> :in `require' > > So, environmental problem here... > >> http://cibuilder.pivotallabs.com:3333/builds/RubyGems-1_9_2-rc2 > > p0 is the latest release for 1.9.2. > > Why is it building ruby on every run? > > This one has failures, but they're not visible in the CI. I suspect it is just truncating because of the annoying YAML warning on a billion lines. If I click on the raw log they're all: > >> /home/pivotal/.rvm/rubies/ruby-1.9.2-rc2/lib/ruby/1.9.1/rubygems.rb:335:in `bin_path': can't find executable rake for rake-0.8.7 (Gem::Exception) > > So I suspect something environmental still. We're going to have to move forward without the CI's for this release since nothing has changed here. There is also a 4th rubygems CI that seems totally borked. Hasn't updated since like april... From ryand-ruby at zenspider.com Wed Dec 29 05:24:05 2010 From: ryand-ruby at zenspider.com (Ryan Davis) Date: Wed, 29 Dec 2010 02:24:05 -0800 Subject: [Rubygems-developers] The 1.4 plan Message-ID: <9194C506-C64C-4157-92A6-7A15D597444A@zenspider.com> I've got a log-jam that looks like this: > hoe is waiting for > rubygems is waiting for > rails is waiting for > rack... there may be more that I don't know about. According to Eric, the only reason why rubygems is held up by rails is because of raggi's work at removing or delaying requires. Apparently rails was dependent upon our require of thread and we'll break them if we release w/o it. So to break this log jam I think I'm gonna add that one require back. This will let us release this month/year and we can take it right back out for a 1.5 release at the end of next month. The current diffs between master and 1.4 are ~700 lines and JB and Eric are reviewing them. That should be done today, I suspect. I currently think we should merge master to 1.4 completely if we can and release by the end of the week. This will let us focus on reconciling differences between ruby-core's branch (on the 1.9 branch) as it weighs in at a HEAVY 4720 lines 'o diff. We can get that merged back to ruby-core with our 1.5 release and then shut down that branch entirely. From luislavena at gmail.com Wed Dec 29 07:12:43 2010 From: luislavena at gmail.com (Luis Lavena) Date: Wed, 29 Dec 2010 09:12:43 -0300 Subject: [Rubygems-developers] download-reporter branch for review In-Reply-To: References: <349D741A-F6DD-494A-9B88-16C81F4C6659@segment7.net> Message-ID: On Wed, Dec 29, 2010 at 7:13 AM, Ryan Davis wrote: > > On Dec 29, 2010, at 01:51 , Eric Hodel wrote: > >> >> We trust your work. ?In the future, Just Do It? ? > > seconded. > Thank you guys for the trust, but... > stop asking pls > I'm asking because don't want to merge something that could generate another of these big threads about breaking backward compatibility and yada yada yada. Anyhow, merged into master. PS: As for 1.9 branch review, I've started doing it to identify the changes that could affect Windows. -- 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 thewoolleyman at gmail.com Wed Dec 29 11:00:25 2010 From: thewoolleyman at gmail.com (Chad Woolley) Date: Wed, 29 Dec 2010 09:00:25 -0700 Subject: [Rubygems-developers] CI Status (was: RubyGemsGitHub build 1e71d86 failed) In-Reply-To: References: Message-ID: On Wed, Dec 29, 2010 at 3:20 AM, Ryan Davis wrote: > > We're going to have to move forward without the CI's for this release since nothing has changed here. > > There is also a 4th rubygems CI that seems totally borked. Hasn't updated since like april... Gonna devote some time this weekend. Holidays are kicking my butt (and no vacation time for me this year). Sorry if I don't get it before the 1.4 release - let me know if that's a real problem and I'll see what I can do the next couple of evenings... -- Chad From noreply at rubyforge.org Wed Dec 29 11:41:37 2010 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 29 Dec 2010 11:41:37 -0500 (EST) Subject: [Rubygems-developers] [ rubygems-Bugs-28807 ] option --no-ri and --no-rdoc make gem install fail without -d Message-ID: <20101229164137.8BDCC1858346@rubyforge.org> Bugs item #28807, was opened at 2010-12-29 17:41 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28807&group_id=126 Category: `gem install` command Group: None Status: Open Resolution: None Priority: 3 Submitted By: Peter Vandenabeele (peter_v) Assigned to: Nobody (None) Summary: option --no-ri and --no-rdoc make gem install fail without -d Initial Comment: Context: pev at pev-desktop:~/data/new-rails$ rvm use 1.8.7 Using /home/pev/.rvm/gems/ruby-1.8.7-p330 pev at pev-desktop:~/data/new-rails$ gem -v 1.3.7 Output of `gem env` and `gem --debug` is below. `gem install rails --no-doc --no-ri` does not function when `-d` is not given as an option. pev at pev-desktop:~/data/new-rails$ rvm gemset create rails3 'rails3' gemset created (/home/pev/.rvm/gems/ruby-1.8.7-p330 at rails3). pev at pev-desktop:~/data/new-rails$ rvm gemset use rails3 Now using gemset 'rails3' pev at pev-desktop:~/data/new-rails$ gem install rails --no-rdoc --no-ri WARNING: RubyGems 1.2+ index not found for: RubyGems will revert to legacy indexes degrading performance. ERROR: Could not find a valid gem 'rails' (>= 0) in any repository When the -d option is also specified, it works as I had expected. pev at pev-desktop:~/data/new-rails$ rvm gemset create rails3 'rails3' gemset created (/home/pev/.rvm/gems/ruby-1.8.7-p330 at rails3). pev at pev-desktop:~/data/new-rails$ rvm gemset use rails3 Now using gemset 'rails3' pev at pev-desktop:~/data/new-rails$ gem install rails -d --no-ri --no-rdoc Successfully installed activesupport-3.0.3 Successfully installed builder-2.1.2 Successfully installed i18n-0.5.0 Successfully installed activemodel-3.0.3 Successfully installed rack-1.2.1 Successfully installed rack-test-0.5.6 Successfully installed rack-mount-0.6.13 Successfully installed tzinfo-0.3.23 Successfully installed abstract-1.0.0 Successfully installed erubis-2.6.6 Successfully installed actionpack-3.0.3 Successfully installed arel-2.0.6 Successfully installed activerecord-3.0.3 Successfully installed activeresource-3.0.3 Successfully installed mime-types-1.16 Successfully installed polyglot-0.3.1 Successfully installed treetop-1.4.9 Successfully installed mail-2.2.13 Successfully installed actionmailer-3.0.3 Successfully installed thor-0.14.6 Successfully installed railties-3.0.3 Successfully installed bundler-1.0.7 Successfully installed rails-3.0.3 23 gems installed The help file says: pev at pev-desktop:~/data/new-rails$ gem help install Usage: gem install GEMNAME [GEMNAME ...] [options] -- --build-flags [options] Options: --platform PLATFORM Specify the platform of gem to install -v, --version VERSION Specify version of gem to install --[no-]prerelease Allow prerelease versions of a gem to be installed. (Only for listed gems) Install/Update Options: -i, --install-dir DIR Gem repository directory to get installed gems -n, --bindir DIR Directory where binary files are located -d, --[no-]rdoc Generate RDoc documentation for the gem on install --[no-]ri Generate RI documentation for the gem on install -E, --[no-]env-shebang Rewrite the shebang line on installed scripts to use /usr/bin/env ... I had expected from this that I can give _either_ -d or --no-rdoc and/or --no-ri. I did not expect that the --no-rdoc or --no-ri option requires the -d option to be functional. I suggest a change where either the --no-rdoc or --no-ri option automatically invoke the -d option. If there is interest, I could try to write a patch (either changing the behavior or the help file). =============== pev at pev-desktop:~/data/new-rails$ gem env RubyGems Environment: - RUBYGEMS VERSION: 1.3.7 - RUBY VERSION: 1.8.7 (2010-12-23 patchlevel 330) [i686-linux] - INSTALLATION DIRECTORY: /home/pev/.rvm/gems/ruby-1.8.7-p330 at rails3 - RUBY EXECUTABLE: /home/pev/.rvm/rubies/ruby-1.8.7-p330/bin/ruby - EXECUTABLE DIRECTORY: /home/pev/.rvm/gems/ruby-1.8.7-p330 at rails3/bin - RUBYGEMS PLATFORMS: - ruby - x86-linux - GEM PATHS: - /home/pev/.rvm/gems/ruby-1.8.7-p330 at rails3 - /home/pev/.rvm/gems/ruby-1.8.7-p330 at global - 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/ ============== pev at pev-desktop:~/data/new-rails$ gem --debug install rails --no-ri --no-rdoc Exception `NameError' at /home/pev/.rvm/rubies/ruby-1.8.7-p330/lib/ruby/site_ruby/1.8/rubygems/command_manager.rb:164 - uninitialized constant Gem::Commands::InstallCommand Exception `Gem::LoadError' at /home/pev/.rvm/rubies/ruby-1.8.7-p330/lib/ruby/site_ruby/1.8/rubygems.rb:779 - Could not find RubyGem test-unit (>= 0) Exception `SocketError' at /home/pev/.rvm/rubies/ruby-1.8.7-p330/lib/ruby/1.8/net/http.rb:560 - getaddrinfo: Name or service not known Exception `Gem::RemoteFetcher::FetchError' at /home/pev/.rvm/rubies/ruby-1.8.7-p330/lib/ruby/site_ruby/1.8/rubygems/remote_fetcher.rb:180 - SocketError: getaddrinfo: Name or service not known (http://gems.rubyforge.org/latest_specs.4.8.gz) Exception `EOFError' at /home/pev/.rvm/rubies/ruby-1.8.7-p330/lib/ruby/1.8/net/protocol.rb:135 - end of file reached Exception `EOFError' at /home/pev/.rvm/rubies/ruby-1.8.7-p330/lib/ruby/1.8/net/protocol.rb:120 - end of file reached Exception `EOFError' at /home/pev/.rvm/rubies/ruby-1.8.7-p330/lib/ruby/1.8/net/http.rb:1060 - end of file reached WARNING: RubyGems 1.2+ index not found for: RubyGems will revert to legacy indexes degrading performance. Exception `Errno::ENOENT' at /home/pev/.rvm/rubies/ruby-1.8.7-p330/lib/ruby/site_ruby/1.8/rubygems/source_info_cache.rb:206 - No such file or directory - /home/pev/.rvm/gems/ruby-1.8.7-p330 at rails3/latest_source_cache Exception `EOFError' at /home/pev/.rvm/rubies/ruby-1.8.7-p330/lib/ruby/1.8/net/protocol.rb:135 - end of file reached Exception `EOFError' at /home/pev/.rvm/rubies/ruby-1.8.7-p330/lib/ruby/1.8/net/protocol.rb:120 - end of file reached Exception `EOFError' at /home/pev/.rvm/rubies/ruby-1.8.7-p330/lib/ruby/1.8/net/http.rb:1060 - end of file reached Updating metadata for 1 gems from http://gems.rubyforge.org/ . complete Bulk updating Gem source index for: http://gems.github.com/ Exception `Gem::GemNotFoundException' at /home/pev/.rvm/rubies/ruby-1.8.7-p330/lib/ruby/site_ruby/1.8/rubygems/dependency_installer.rb:215 - Could not find a valid gem 'rails' (>= 0) locally or in a repository ERROR: Could not find a valid gem 'rails' (>= 0) in any repository =================== HTH, Peter ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28807&group_id=126 From noreply at rubyforge.org Wed Dec 29 11:50:11 2010 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 29 Dec 2010 11:50:11 -0500 (EST) Subject: [Rubygems-developers] [ rubygems-Bugs-28807 ] option --no-ri and --no-rdoc make gem install fail without -d Message-ID: <20101229165011.58149167831B@rubyforge.org> Bugs item #28807, was opened at 2010-12-29 13:41 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28807&group_id=126 Category: `gem install` command Group: None >Status: Closed >Resolution: Rejected Priority: 3 Submitted By: Peter Vandenabeele (peter_v) Assigned to: Nobody (None) Summary: option --no-ri and --no-rdoc make gem install fail without -d Initial Comment: Context: pev at pev-desktop:~/data/new-rails$ rvm use 1.8.7 Using /home/pev/.rvm/gems/ruby-1.8.7-p330 pev at pev-desktop:~/data/new-rails$ gem -v 1.3.7 Output of `gem env` and `gem --debug` is below. `gem install rails --no-doc --no-ri` does not function when `-d` is not given as an option. pev at pev-desktop:~/data/new-rails$ rvm gemset create rails3 'rails3' gemset created (/home/pev/.rvm/gems/ruby-1.8.7-p330 at rails3). pev at pev-desktop:~/data/new-rails$ rvm gemset use rails3 Now using gemset 'rails3' pev at pev-desktop:~/data/new-rails$ gem install rails --no-rdoc --no-ri WARNING: RubyGems 1.2+ index not found for: RubyGems will revert to legacy indexes degrading performance. ERROR: Could not find a valid gem 'rails' (>= 0) in any repository When the -d option is also specified, it works as I had expected. pev at pev-desktop:~/data/new-rails$ rvm gemset create rails3 'rails3' gemset created (/home/pev/.rvm/gems/ruby-1.8.7-p330 at rails3). pev at pev-desktop:~/data/new-rails$ rvm gemset use rails3 Now using gemset 'rails3' pev at pev-desktop:~/data/new-rails$ gem install rails -d --no-ri --no-rdoc Successfully installed activesupport-3.0.3 Successfully installed builder-2.1.2 Successfully installed i18n-0.5.0 Successfully installed activemodel-3.0.3 Successfully installed rack-1.2.1 Successfully installed rack-test-0.5.6 Successfully installed rack-mount-0.6.13 Successfully installed tzinfo-0.3.23 Successfully installed abstract-1.0.0 Successfully installed erubis-2.6.6 Successfully installed actionpack-3.0.3 Successfully installed arel-2.0.6 Successfully installed activerecord-3.0.3 Successfully installed activeresource-3.0.3 Successfully installed mime-types-1.16 Successfully installed polyglot-0.3.1 Successfully installed treetop-1.4.9 Successfully installed mail-2.2.13 Successfully installed actionmailer-3.0.3 Successfully installed thor-0.14.6 Successfully installed railties-3.0.3 Successfully installed bundler-1.0.7 Successfully installed rails-3.0.3 23 gems installed The help file says: pev at pev-desktop:~/data/new-rails$ gem help install Usage: gem install GEMNAME [GEMNAME ...] [options] -- --build-flags [options] Options: --platform PLATFORM Specify the platform of gem to install -v, --version VERSION Specify version of gem to install --[no-]prerelease Allow prerelease versions of a gem to be installed. (Only for listed gems) Install/Update Options: -i, --install-dir DIR Gem repository directory to get installed gems -n, --bindir DIR Directory where binary files are located -d, --[no-]rdoc Generate RDoc documentation for the gem on install --[no-]ri Generate RI documentation for the gem on install -E, --[no-]env-shebang Rewrite the shebang line on installed scripts to use /usr/bin/env ... I had expected from this that I can give _either_ -d or --no-rdoc and/or --no-ri. I did not expect that the --no-rdoc or --no-ri option requires the -d option to be functional. I suggest a change where either the --no-rdoc or --no-ri option automatically invoke the -d option. If there is interest, I could try to write a patch (either changing the behavior or the help file). =============== pev at pev-desktop:~/data/new-rails$ gem env RubyGems Environment: - RUBYGEMS VERSION: 1.3.7 - RUBY VERSION: 1.8.7 (2010-12-23 patchlevel 330) [i686-linux] - INSTALLATION DIRECTORY: /home/pev/.rvm/gems/ruby-1.8.7-p330 at rails3 - RUBY EXECUTABLE: /home/pev/.rvm/rubies/ruby-1.8.7-p330/bin/ruby - EXECUTABLE DIRECTORY: /home/pev/.rvm/gems/ruby-1.8.7-p330 at rails3/bin - RUBYGEMS PLATFORMS: - ruby - x86-linux - GEM PATHS: - /home/pev/.rvm/gems/ruby-1.8.7-p330 at rails3 - /home/pev/.rvm/gems/ruby-1.8.7-p330 at global - 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/ ============== pev at pev-desktop:~/data/new-rails$ gem --debug install rails --no-ri --no-rdoc Exception `NameError' at /home/pev/.rvm/rubies/ruby-1.8.7-p330/lib/ruby/site_ruby/1.8/rubygems/command_manager.rb:164 - uninitialized constant Gem::Commands::InstallCommand Exception `Gem::LoadError' at /home/pev/.rvm/rubies/ruby-1.8.7-p330/lib/ruby/site_ruby/1.8/rubygems.rb:779 - Could not find RubyGem test-unit (>= 0) Exception `SocketError' at /home/pev/.rvm/rubies/ruby-1.8.7-p330/lib/ruby/1.8/net/http.rb:560 - getaddrinfo: Name or service not known Exception `Gem::RemoteFetcher::FetchError' at /home/pev/.rvm/rubies/ruby-1.8.7-p330/lib/ruby/site_ruby/1.8/rubygems/remote_fetcher.rb:180 - SocketError: getaddrinfo: Name or service not known (http://gems.rubyforge.org/latest_specs.4.8.gz) Exception `EOFError' at /home/pev/.rvm/rubies/ruby-1.8.7-p330/lib/ruby/1.8/net/protocol.rb:135 - end of file reached Exception `EOFError' at /home/pev/.rvm/rubies/ruby-1.8.7-p330/lib/ruby/1.8/net/protocol.rb:120 - end of file reached Exception `EOFError' at /home/pev/.rvm/rubies/ruby-1.8.7-p330/lib/ruby/1.8/net/http.rb:1060 - end of file reached WARNING: RubyGems 1.2+ index not found for: RubyGems will revert to legacy indexes degrading performance. Exception `Errno::ENOENT' at /home/pev/.rvm/rubies/ruby-1.8.7-p330/lib/ruby/site_ruby/1.8/rubygems/source_info_cache.rb:206 - No such file or directory - /home/pev/.rvm/gems/ruby-1.8.7-p330 at rails3/latest_source_cache Exception `EOFError' at /home/pev/.rvm/rubies/ruby-1.8.7-p330/lib/ruby/1.8/net/protocol.rb:135 - end of file reached Exception `EOFError' at /home/pev/.rvm/rubies/ruby-1.8.7-p330/lib/ruby/1.8/net/protocol.rb:120 - end of file reached Exception `EOFError' at /home/pev/.rvm/rubies/ruby-1.8.7-p330/lib/ruby/1.8/net/http.rb:1060 - end of file reached Updating metadata for 1 gems from http://gems.rubyforge.org/ . complete Bulk updating Gem source index for: http://gems.github.com/ Exception `Gem::GemNotFoundException' at /home/pev/.rvm/rubies/ruby-1.8.7-p330/lib/ruby/site_ruby/1.8/rubygems/dependency_installer.rb:215 - Could not find a valid gem 'rails' (>= 0) locally or in a repository ERROR: Could not find a valid gem 'rails' (>= 0) in any repository =================== HTH, Peter ---------------------------------------------------------------------- >Comment By: Luis Lavena (luislavena) Date: 2010-12-29 13:50 Message: Peter, You're having a fluctuating internet connection problem it seems, as the first message: WARNING: RubyGems 1.2+ index not found for: RubyGems will revert to legacy indexes degrading performance. ERROR: Could not find a valid gem 'rails' (>= 0) in any repository Indicates that couldn't retrieve the quick index from rubygems.org And now looking into your gem env: - REMOTE SOURCES: - http://gems.rubyforge.org/ - http://gems.github.com/ Seems you're pointing to the old deprecated gems.rubyforge.org Please change your sources to http://rubygems.org and try again. Closing this as is not a bug, is a network connectivity issue associated with a deprecated repository. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28807&group_id=126 From noreply at rubyforge.org Wed Dec 29 13:26:53 2010 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 29 Dec 2010 13:26:53 -0500 (EST) Subject: [Rubygems-developers] [ rubygems-Bugs-28807 ] option --no-ri and --no-rdoc make gem install fail without -d Message-ID: <20101229182653.A41711858317@rubyforge.org> Bugs item #28807, was opened at 2010-12-29 17:41 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28807&group_id=126 Category: `gem install` command Group: None Status: Closed Resolution: Rejected Priority: 3 Submitted By: Peter Vandenabeele (peter_v) Assigned to: Nobody (None) Summary: option --no-ri and --no-rdoc make gem install fail without -d Initial Comment: Context: pev at pev-desktop:~/data/new-rails$ rvm use 1.8.7 Using /home/pev/.rvm/gems/ruby-1.8.7-p330 pev at pev-desktop:~/data/new-rails$ gem -v 1.3.7 Output of `gem env` and `gem --debug` is below. `gem install rails --no-doc --no-ri` does not function when `-d` is not given as an option. pev at pev-desktop:~/data/new-rails$ rvm gemset create rails3 'rails3' gemset created (/home/pev/.rvm/gems/ruby-1.8.7-p330 at rails3). pev at pev-desktop:~/data/new-rails$ rvm gemset use rails3 Now using gemset 'rails3' pev at pev-desktop:~/data/new-rails$ gem install rails --no-rdoc --no-ri WARNING: RubyGems 1.2+ index not found for: RubyGems will revert to legacy indexes degrading performance. ERROR: Could not find a valid gem 'rails' (>= 0) in any repository When the -d option is also specified, it works as I had expected. pev at pev-desktop:~/data/new-rails$ rvm gemset create rails3 'rails3' gemset created (/home/pev/.rvm/gems/ruby-1.8.7-p330 at rails3). pev at pev-desktop:~/data/new-rails$ rvm gemset use rails3 Now using gemset 'rails3' pev at pev-desktop:~/data/new-rails$ gem install rails -d --no-ri --no-rdoc Successfully installed activesupport-3.0.3 Successfully installed builder-2.1.2 Successfully installed i18n-0.5.0 Successfully installed activemodel-3.0.3 Successfully installed rack-1.2.1 Successfully installed rack-test-0.5.6 Successfully installed rack-mount-0.6.13 Successfully installed tzinfo-0.3.23 Successfully installed abstract-1.0.0 Successfully installed erubis-2.6.6 Successfully installed actionpack-3.0.3 Successfully installed arel-2.0.6 Successfully installed activerecord-3.0.3 Successfully installed activeresource-3.0.3 Successfully installed mime-types-1.16 Successfully installed polyglot-0.3.1 Successfully installed treetop-1.4.9 Successfully installed mail-2.2.13 Successfully installed actionmailer-3.0.3 Successfully installed thor-0.14.6 Successfully installed railties-3.0.3 Successfully installed bundler-1.0.7 Successfully installed rails-3.0.3 23 gems installed The help file says: pev at pev-desktop:~/data/new-rails$ gem help install Usage: gem install GEMNAME [GEMNAME ...] [options] -- --build-flags [options] Options: --platform PLATFORM Specify the platform of gem to install -v, --version VERSION Specify version of gem to install --[no-]prerelease Allow prerelease versions of a gem to be installed. (Only for listed gems) Install/Update Options: -i, --install-dir DIR Gem repository directory to get installed gems -n, --bindir DIR Directory where binary files are located -d, --[no-]rdoc Generate RDoc documentation for the gem on install --[no-]ri Generate RI documentation for the gem on install -E, --[no-]env-shebang Rewrite the shebang line on installed scripts to use /usr/bin/env ... I had expected from this that I can give _either_ -d or --no-rdoc and/or --no-ri. I did not expect that the --no-rdoc or --no-ri option requires the -d option to be functional. I suggest a change where either the --no-rdoc or --no-ri option automatically invoke the -d option. If there is interest, I could try to write a patch (either changing the behavior or the help file). =============== pev at pev-desktop:~/data/new-rails$ gem env RubyGems Environment: - RUBYGEMS VERSION: 1.3.7 - RUBY VERSION: 1.8.7 (2010-12-23 patchlevel 330) [i686-linux] - INSTALLATION DIRECTORY: /home/pev/.rvm/gems/ruby-1.8.7-p330 at rails3 - RUBY EXECUTABLE: /home/pev/.rvm/rubies/ruby-1.8.7-p330/bin/ruby - EXECUTABLE DIRECTORY: /home/pev/.rvm/gems/ruby-1.8.7-p330 at rails3/bin - RUBYGEMS PLATFORMS: - ruby - x86-linux - GEM PATHS: - /home/pev/.rvm/gems/ruby-1.8.7-p330 at rails3 - /home/pev/.rvm/gems/ruby-1.8.7-p330 at global - 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/ ============== pev at pev-desktop:~/data/new-rails$ gem --debug install rails --no-ri --no-rdoc Exception `NameError' at /home/pev/.rvm/rubies/ruby-1.8.7-p330/lib/ruby/site_ruby/1.8/rubygems/command_manager.rb:164 - uninitialized constant Gem::Commands::InstallCommand Exception `Gem::LoadError' at /home/pev/.rvm/rubies/ruby-1.8.7-p330/lib/ruby/site_ruby/1.8/rubygems.rb:779 - Could not find RubyGem test-unit (>= 0) Exception `SocketError' at /home/pev/.rvm/rubies/ruby-1.8.7-p330/lib/ruby/1.8/net/http.rb:560 - getaddrinfo: Name or service not known Exception `Gem::RemoteFetcher::FetchError' at /home/pev/.rvm/rubies/ruby-1.8.7-p330/lib/ruby/site_ruby/1.8/rubygems/remote_fetcher.rb:180 - SocketError: getaddrinfo: Name or service not known (http://gems.rubyforge.org/latest_specs.4.8.gz) Exception `EOFError' at /home/pev/.rvm/rubies/ruby-1.8.7-p330/lib/ruby/1.8/net/protocol.rb:135 - end of file reached Exception `EOFError' at /home/pev/.rvm/rubies/ruby-1.8.7-p330/lib/ruby/1.8/net/protocol.rb:120 - end of file reached Exception `EOFError' at /home/pev/.rvm/rubies/ruby-1.8.7-p330/lib/ruby/1.8/net/http.rb:1060 - end of file reached WARNING: RubyGems 1.2+ index not found for: RubyGems will revert to legacy indexes degrading performance. Exception `Errno::ENOENT' at /home/pev/.rvm/rubies/ruby-1.8.7-p330/lib/ruby/site_ruby/1.8/rubygems/source_info_cache.rb:206 - No such file or directory - /home/pev/.rvm/gems/ruby-1.8.7-p330 at rails3/latest_source_cache Exception `EOFError' at /home/pev/.rvm/rubies/ruby-1.8.7-p330/lib/ruby/1.8/net/protocol.rb:135 - end of file reached Exception `EOFError' at /home/pev/.rvm/rubies/ruby-1.8.7-p330/lib/ruby/1.8/net/protocol.rb:120 - end of file reached Exception `EOFError' at /home/pev/.rvm/rubies/ruby-1.8.7-p330/lib/ruby/1.8/net/http.rb:1060 - end of file reached Updating metadata for 1 gems from http://gems.rubyforge.org/ . complete Bulk updating Gem source index for: http://gems.github.com/ Exception `Gem::GemNotFoundException' at /home/pev/.rvm/rubies/ruby-1.8.7-p330/lib/ruby/site_ruby/1.8/rubygems/dependency_installer.rb:215 - Could not find a valid gem 'rails' (>= 0) locally or in a repository ERROR: Could not find a valid gem 'rails' (>= 0) in any repository =================== HTH, Peter ---------------------------------------------------------------------- >Comment By: Peter Vandenabeele (peter_v) Date: 2010-12-29 19:26 Message: Luis, Many thanks, that solved it ! While I was using a shiny new version of rubygems in ~/.rvm/rubies/ruby-1.8.7-p330/bin/gem I was indeed still using an outdated version of .gemrc that was placed there with root permissions by some older installation process (Debian, ree ?). Now it works as expected. Thanks again, Peter ---------------------------------------------------------------------- Comment By: Luis Lavena (luislavena) Date: 2010-12-29 17:50 Message: Peter, You're having a fluctuating internet connection problem it seems, as the first message: WARNING: RubyGems 1.2+ index not found for: RubyGems will revert to legacy indexes degrading performance. ERROR: Could not find a valid gem 'rails' (>= 0) in any repository Indicates that couldn't retrieve the quick index from rubygems.org And now looking into your gem env: - REMOTE SOURCES: - http://gems.rubyforge.org/ - http://gems.github.com/ Seems you're pointing to the old deprecated gems.rubyforge.org Please change your sources to http://rubygems.org and try again. Closing this as is not a bug, is a network connectivity issue associated with a deprecated repository. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28807&group_id=126 From ryand-ruby at zenspider.com Wed Dec 29 19:39:34 2010 From: ryand-ruby at zenspider.com (Ryan Davis) Date: Wed, 29 Dec 2010 16:39:34 -0800 Subject: [Rubygems-developers] The 1.4 plan In-Reply-To: <9194C506-C64C-4157-92A6-7A15D597444A@zenspider.com> References: <9194C506-C64C-4157-92A6-7A15D597444A@zenspider.com> Message-ID: <3575668E-4909-4A60-91DD-8B6B653B15AA@zenspider.com> On Dec 29, 2010, at 02:24 , Ryan Davis wrote: > I've got a log-jam that looks like this: > >> hoe is waiting for >> rubygems is waiting for >> rails is waiting for >> rack... > > > there may be more that I don't know about. > > According to Eric, the only reason why rubygems is held up by rails is because of raggi's work at removing or delaying requires. Apparently rails was dependent upon our require of thread and we'll break them if we release w/o it. > > So to break this log jam I think I'm gonna add that one require back. done and committed to master and merged to 1.4. > This will let us release this month/year and we can take it right back out for a 1.5 release at the end of next month. The current diffs between master and 1.4 are ~700 lines and JB and Eric are reviewing them. That should be done today, I suspect. > > I currently think we should merge master to 1.4 completely if we can and release by the end of the week. OK. I've cherry picked from master to 1.4 all but this commit: commit 183a2b6bae927eab8e32f476023bca00066e6aa7 Author: John Barnette Date: Thu Dec 9 08:07:32 2010 -0800 Remove deprecated Gem::Dependency#version_requirement methods. I'd be really surprised if this didn't break Rails 2.x. We'll sort it out during the prerelease cycle. I want to release what we have on the 1.4 branch. It needs some beatings. Can we get ppl to test against the 1.4 branch and report any errors to the list asap? Esp needed: windows, REE, linux. From ryand-ruby at zenspider.com Wed Dec 29 20:11:34 2010 From: ryand-ruby at zenspider.com (Ryan Davis) Date: Wed, 29 Dec 2010 17:11:34 -0800 Subject: [Rubygems-developers] The 1.4 plan In-Reply-To: <3575668E-4909-4A60-91DD-8B6B653B15AA@zenspider.com> References: <9194C506-C64C-4157-92A6-7A15D597444A@zenspider.com> <3575668E-4909-4A60-91DD-8B6B653B15AA@zenspider.com> Message-ID: On Dec 29, 2010, at 16:39 , Ryan Davis wrote: > OK. I've cherry picked from master to 1.4 all but this commit: that wasn't true at the time. Luis pushed the progress indicator stuff to master while I was pulling into 1.4. I've pulled his commits to 1.4 and now `git diff 1.4 master` only show JB's commit as the thing excluded from 1.4 From headius at headius.com Wed Dec 29 21:14:45 2010 From: headius at headius.com (Charles Oliver Nutter) Date: Wed, 29 Dec 2010 20:14:45 -0600 Subject: [Rubygems-developers] The 1.4 plan In-Reply-To: <3575668E-4909-4A60-91DD-8B6B653B15AA@zenspider.com> References: <9194C506-C64C-4157-92A6-7A15D597444A@zenspider.com> <3575668E-4909-4A60-91DD-8B6B653B15AA@zenspider.com> Message-ID: On Wed, Dec 29, 2010 at 6:39 PM, Ryan Davis wrote: > OK. I've cherry picked from master to 1.4 all but this commit: I'll probably regret asking this, but... Does that mean the plugin change has been merged to 1.4 also? Is this going against the 1.4/2.0 plan mentioned earlier? I don't care one way or another, as long as the plugin change gets out there some day soon... - Charlie From ryand-ruby at zenspider.com Thu Dec 30 00:24:41 2010 From: ryand-ruby at zenspider.com (Ryan Davis) Date: Wed, 29 Dec 2010 21:24:41 -0800 Subject: [Rubygems-developers] The 1.4 plan In-Reply-To: References: <9194C506-C64C-4157-92A6-7A15D597444A@zenspider.com> <3575668E-4909-4A60-91DD-8B6B653B15AA@zenspider.com> Message-ID: On Dec 29, 2010, at 18:14 , Charles Oliver Nutter wrote: > On Wed, Dec 29, 2010 at 6:39 PM, Ryan Davis wrote: >> OK. I've cherry picked from master to 1.4 all but this commit: > > I'll probably regret asking this, but... > > Does that mean the plugin change has been merged to 1.4 also? Is this > going against the 1.4/2.0 plan mentioned earlier? It is going in 1.4. I haven't seen any credible evidence that it breaks anything significant, it has obvious benefit, and Eric's argument for 2.0 wasn't very strong since this isn't a backwards incompatible API change. > I don't care one way or another, as long as the plugin change gets out > there some day soon... It'll go out in 2010 barring showstoppers we can't fix in time. From luislavena at gmail.com Thu Dec 30 06:39:52 2010 From: luislavena at gmail.com (Luis Lavena) Date: Thu, 30 Dec 2010 08:39:52 -0300 Subject: [Rubygems-developers] The 1.4 plan In-Reply-To: <3575668E-4909-4A60-91DD-8B6B653B15AA@zenspider.com> References: <9194C506-C64C-4157-92A6-7A15D597444A@zenspider.com> <3575668E-4909-4A60-91DD-8B6B653B15AA@zenspider.com> Message-ID: On Wed, Dec 29, 2010 at 9:39 PM, Ryan Davis wrote: > > I want to release what we have on the 1.4 branch. It needs some beatings. Can we get ppl to test against the 1.4 branch and report any errors to the list asap? Esp needed: windows, REE, linux. > ruby 1.8.7 (2010-12-23 patchlevel 330) [i386-mingw32] 770 tests, 2561 assertions, 0 failures, 0 errors, 13 skips Installing it right now and will actively use during the day against Bundler and Isolate. Will report any problem to this thread. -- 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 erik at hollensbe.org Thu Dec 30 07:26:28 2010 From: erik at hollensbe.org (Erik Hollensbe) Date: Thu, 30 Dec 2010 07:26:28 -0500 Subject: [Rubygems-developers] The 1.4 plan In-Reply-To: <3575668E-4909-4A60-91DD-8B6B653B15AA@zenspider.com> References: <9194C506-C64C-4157-92A6-7A15D597444A@zenspider.com> <3575668E-4909-4A60-91DD-8B6B653B15AA@zenspider.com> Message-ID: <472DC37E-3D01-4E68-8A23-F3FAC58F5F32@hollensbe.org> On Dec 29, 2010, at 7:39 PM, Ryan Davis wrote: > I want to release what we have on the 1.4 branch. It needs some beatings. Can we get ppl to test against the 1.4 branch and report any errors to the list asap? Esp needed: windows, REE, linux. REE 2010.02 on Ubuntu 10.10 via RVM - looking good. I'll have two posts for 1.9.2 and 1.8.7 in a few minutes here. .........................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................../home/ubuntu/rubygems/test/../lib/rubygems/user_interaction.rb:461: warning: instance variable @progress not initialized ..../home/ubuntu/rubygems/test/../lib/rubygems/user_interaction.rb:461: warning: instance variable @progress not initialized ......../home/ubuntu/rubygems/test/../lib/rubygems/user_interaction.rb:461: warning: instance variable @progress not initialized .................................................................. Finished tests in 21.058530s, 36.8972 tests/s, 125.2224 assertions/s. 777 tests, 2637 assertions, 0 failures, 0 errors, 0 skips ./lib/rubygems/test_utilities.rb:29: warning: method redefined; discarding old initialize ./lib/rubygems/test_utilities.rb:34: warning: method redefined; discarding old find_data ./lib/rubygems/test_utilities.rb:46: warning: method redefined; discarding old fetch_path ./lib/rubygems/test_utilities.rb:61: warning: method redefined; discarding old open_uri_or_path ./lib/rubygems/test_utilities.rb:71: warning: method redefined; discarding old request ./lib/rubygems/test_utilities.rb:84: warning: method redefined; discarding old fetch_size ./lib/rubygems/test_utilities.rb:99: warning: method redefined; discarding old download ./lib/rubygems/test_utilities.rb:121: warning: redefine fetcher= ./lib/rubygems/test_utilities.rb:138: warning: method redefined; discarding old initialize ./lib/rubygems/test_utilities.rb:145: warning: method redefined; discarding old method_missing ./lib/rubygems/test_utilities.rb:149: warning: method redefined; discarding old respond_to? ./lib/rubygems/test_utilities.rb:153: warning: method redefined; discarding old string Loaded suite . Started Finished in 0.000121 seconds. 0 tests, 0 assertions, 0 failures, 0 errors From erik at hollensbe.org Thu Dec 30 07:41:29 2010 From: erik at hollensbe.org (Erik Hollensbe) Date: Thu, 30 Dec 2010 07:41:29 -0500 Subject: [Rubygems-developers] The 1.4 plan In-Reply-To: <3575668E-4909-4A60-91DD-8B6B653B15AA@zenspider.com> References: <9194C506-C64C-4157-92A6-7A15D597444A@zenspider.com> <3575668E-4909-4A60-91DD-8B6B653B15AA@zenspider.com> Message-ID: <305380CA-14E5-4C1D-8478-C7518955041E@hollensbe.org> On Dec 29, 2010, at 7:39 PM, Ryan Davis wrote: > I want to release what we have on the 1.4 branch. It needs some beatings. Can we get ppl to test against the 1.4 branch and report any errors to the list asap? Esp needed: windows, REE, linux. 1.8.7-p330 passes fine, but 1.9.2-p136 is causing some headaches: /home/ubuntu/rubygems/lib/rubygems/security.rb:688: warning: shadowing outer local variable - name /home/ubuntu/rubygems/lib/rubygems/remote_fetcher.rb:9:in `': uninitialized constant Gem::UserInteraction (NameError) from /home/ubuntu/rubygems/lib/rubygems/remote_fetcher.rb:7:in `' from /home/ubuntu/rubygems/lib/rubygems/custom_require.rb:29:in `require' from /home/ubuntu/rubygems/lib/rubygems/custom_require.rb:29:in `require' from /home/ubuntu/rubygems/lib/rubygems/test_utilities.rb:3:in `' from /home/ubuntu/rubygems/lib/rubygems/custom_require.rb:29:in `require' from /home/ubuntu/rubygems/lib/rubygems/custom_require.rb:29:in `require' from /home/ubuntu/rubygems/test/gemutilities.rb:15:in `' from /home/ubuntu/rubygems/lib/rubygems/custom_require.rb:29:in `require' from /home/ubuntu/rubygems/lib/rubygems/custom_require.rb:29:in `require' from /home/ubuntu/rubygems/test/test_gem_commands_query_command.rb:1:in `' from /home/ubuntu/rubygems/lib/rubygems/custom_require.rb:29:in `require' from /home/ubuntu/rubygems/lib/rubygems/custom_require.rb:29:in `require' from -e:1:in `
' rake aborted! Command failed with status (1): [/usr/local/rvm/rubies/ruby-1.9.2-p136/bin/...] I'm not sure if this "matters" or not, but I figured it was worth mentioning. -Erik From luislavena at gmail.com Thu Dec 30 07:44:58 2010 From: luislavena at gmail.com (Luis Lavena) Date: Thu, 30 Dec 2010 09:44:58 -0300 Subject: [Rubygems-developers] The 1.4 plan In-Reply-To: <305380CA-14E5-4C1D-8478-C7518955041E@hollensbe.org> References: <9194C506-C64C-4157-92A6-7A15D597444A@zenspider.com> <3575668E-4909-4A60-91DD-8B6B653B15AA@zenspider.com> <305380CA-14E5-4C1D-8478-C7518955041E@hollensbe.org> Message-ID: On Thu, Dec 30, 2010 at 9:41 AM, Erik Hollensbe wrote: > > On Dec 29, 2010, at 7:39 PM, Ryan Davis wrote: >> I want to release what we have on the 1.4 branch. It needs some beatings. Can we get ppl to test against the 1.4 branch and report any errors to the list asap? Esp needed: windows, REE, linux. > > 1.8.7-p330 passes fine, but 1.9.2-p136 is causing some headaches: > > /home/ubuntu/rubygems/lib/rubygems/security.rb:688: warning: shadowing outer local variable - name > /home/ubuntu/rubygems/lib/rubygems/remote_fetcher.rb:9:in `': uninitialized constant Gem::UserInteraction (NameError) Over here too, not even ruby -Ilib bin/gem works since rubygems-update will be released, Users using 1.9.2 will be able to do "gem update --system" and bork their installations. I'm looking into the 1.9 branch for the changes and see what can be merged. I don't think 1.4.0 should go out without 1.9 compatibility. -- 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 Thu Dec 30 15:03:08 2010 From: ryand-ruby at zenspider.com (Ryan Davis) Date: Thu, 30 Dec 2010 12:03:08 -0800 Subject: [Rubygems-developers] The 1.4 plan In-Reply-To: References: <9194C506-C64C-4157-92A6-7A15D597444A@zenspider.com> <3575668E-4909-4A60-91DD-8B6B653B15AA@zenspider.com> <305380CA-14E5-4C1D-8478-C7518955041E@hollensbe.org> Message-ID: On Dec 30, 2010, at 04:44 , Luis Lavena wrote: > Over here too, not even ruby -Ilib bin/gem works > > since rubygems-update will be released, Users using 1.9.2 will be able > to do "gem update --system" and bork their installations. > > I'm looking into the 1.9 branch for the changes and see what can be merged. > > I don't think 1.4.0 should go out without 1.9 compatibility. Sorry, but unless compelling evidence comes in, I'm gonna override. All the 1.3s that shipped since 1.9 have had the same issue. Nobody (afaik) has been able to _properly_ upgrade 1.9 since 1.9 shipped (there are hacky ways, but I'm talking about gem update --system). We're trying to address that in ruby-core, but with the current situation with the 1.9 prelude there is little we can do at this point. From luislavena at gmail.com Thu Dec 30 15:13:59 2010 From: luislavena at gmail.com (Luis Lavena) Date: Thu, 30 Dec 2010 17:13:59 -0300 Subject: [Rubygems-developers] The 1.4 plan In-Reply-To: References: <9194C506-C64C-4157-92A6-7A15D597444A@zenspider.com> <3575668E-4909-4A60-91DD-8B6B653B15AA@zenspider.com> <305380CA-14E5-4C1D-8478-C7518955041E@hollensbe.org> Message-ID: On Thu, Dec 30, 2010 at 5:03 PM, Ryan Davis wrote: > > Sorry, but unless compelling evidence comes in, I'm gonna override. All the 1.3s that shipped since 1.9 have had the same issue. > > Nobody (afaik) has been able to _properly_ upgrade 1.9 since 1.9 shipped (there are hacky ways, but I'm talking about gem update --system). We're trying to address that in ruby-core, but with the current situation with the 1.9 prelude there is little we can do at this point. > OK, I can live with that, but expect a flood of reports about issue with gem update --system for 1.9.1 and 1.9.2 users. -- 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 headius at headius.com Fri Dec 31 01:57:10 2010 From: headius at headius.com (Charles Oliver Nutter) Date: Fri, 31 Dec 2010 00:57:10 -0600 Subject: [Rubygems-developers] The 1.4 plan In-Reply-To: References: <9194C506-C64C-4157-92A6-7A15D597444A@zenspider.com> <3575668E-4909-4A60-91DD-8B6B653B15AA@zenspider.com> <305380CA-14E5-4C1D-8478-C7518955041E@hollensbe.org> Message-ID: On Thu, Dec 30, 2010 at 2:13 PM, Luis Lavena wrote: > OK, I can live with that, but expect a flood of reports about issue > with gem update --system for 1.9.1 and 1.9.2 users. FWIW, JRuby's 1.9 mode has used (and ideally will continue to use) the exact same RubyGems install that 1.8 mode does. gem update --system *should* work properly in JRuby, 1.8 or 1.9 be damned. - Charlie From ryand-ruby at zenspider.com Fri Dec 31 16:25:48 2010 From: ryand-ruby at zenspider.com (Ryan Davis) Date: Fri, 31 Dec 2010 13:25:48 -0800 Subject: [Rubygems-developers] [ANN] rubygems 1.4.0 Released Message-ID: <3E51CD6B-5C62-487C-B71F-347E07AA8242@zenspider.com> rubygems version 1.4.0 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: Ruby 1.9 ships with rubygems and contains a very buggy "gem-prelude". It is a gem loading system that can interfere with updating rubygems itself. We do NOT recommend you update to rubygems 1.4 if you're running ruby 1.9.x until we get that sorted out in a future ruby release. If you absolutely hate kittens and you _must_ upgrade, you're going to have to do something really hokey like: % alias ruby19="ruby19 --disable-gems" % alias gem19="ruby19 --disable-gems -S gem" Even deleting the stock rubygems in 1.9 doesn't fix this situation. ######################################################################## If you don't have any RubyGems install, there is still the pre-gem approach to getting software, doing it manually: 1. Download from: https://rubygems.org/pages/download 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.4.0 / 2010-12-31 NOTE: In order to better maintain rubygems and to get it in sync with the world (eg, 1.9's 1.3.7 is different from our 1.3.7), rubygems is switching to a 4-6 week release schedule. This release is the precursor to that process and as such may be a bit on the wild side! You have been warned! NOTE: We've switched to git/github. See README.rdoc for details. New features: * Added --launch option to `gem server`. (gthiesfeld) * Added fuzzy name matching on install failures. (gstark/presidentbeef) * Allow searching w/ file extensions: gem which fileutils.rb * Progress indicator during download (Ryan Melton) * Speed up Gem::Version#<=> by 2-3x in common cases. (raggi) * --source is now additive with your current sources. Use --clear-sources first to maintain previous behavior. Bug fixes: * Dependency "~>"s now respect lower-bound prerelease versions. * Ensure the gem directories exist on download. * Expand Windows user home candidates for Ruby 1.8. Bug #28371 & #28494 * Fix find_files to order by version. * Fix ivar typo. [Josh Peek] * Normalized requires and made many of them lazy. Do not depend on rubygems to require stdlib stuff for you. (raggi/tmm1) * Treat 1.0.a10 like 1.0.a.10 for sorting, etc. Fixes #27903. (dchelimsky) From noreply at rubyforge.org Fri Dec 31 18:23:33 2010 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 31 Dec 2010 18:23:33 -0500 (EST) Subject: [Rubygems-developers] [ rubygems-Bugs-28746 ] gem install complains of frozen filename on 1.8.7-p302 Message-ID: <20101231232334.0A94A1858346@rubyforge.org> Bugs item #28746, was opened at 2010-11-23 06:39 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28746&group_id=126 Category: `gem install` command Group: next Status: Open Resolution: None Priority: 3 Submitted By: Erik Hollensbe (erikh) >Assigned to: Luis Lavena (luislavena) Summary: gem install complains of frozen filename on 1.8.7-p302 Initial Comment: This patch solves this issue, although it may not be satisfactory. Best I can tell this is not a gems issue but a side-effect of it using optparse. https://gist.github.com/b50b26a6e5cc2124ffee ---------------------------------------------------------------------- >Comment By: Luis Lavena (luislavena) Date: 2010-12-31 20:23 Message: Hello Eric, Can you provide more information about gem install issues? which gems this happens? which version of Ruby? Try to include the whole "gem env" information to help us debug this issue. I've been using p302 for quite some time and never encountered this issue. Thank you. ---------------------------------------------------------------------- Comment By: Erik Hollensbe (erikh) Date: 2010-11-23 06:39 Message: gem build... gah! sorry. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28746&group_id=126 From noreply at rubyforge.org Fri Dec 31 20:32:28 2010 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 31 Dec 2010 20:32:28 -0500 (EST) Subject: [Rubygems-developers] [ rubygems-Bugs-28399 ] rubygems should use RbConfig::CONFIG['make-prog'] Message-ID: <20110101013228.C05E11858356@rubyforge.org> Bugs item #28399, was opened at 2010-07-17 22:38 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28399&group_id=126 Category: None Group: None >Status: Closed Resolution: Accepted Priority: 3 Submitted By: Greg Hazel (ghazel) Assigned to: Luis Lavena (luislavena) Summary: rubygems should use RbConfig::CONFIG['make-prog'] Initial Comment: Similar to mkmf.rb, rubygems should use Config['make-prog'] if it is set. This allows per-ruby configuration of which "make" to use. mkmf.rb does: $make = with_config("make-prog", ENV["MAKE"] || "make") make, = Shellwords.shellwords($make) $nmake = nil case when $mswin $nmake = ?m if /nmake/i =~ make when $bccwin $nmake = ?b if /Borland/i =~ `#{make} -h` end rubygems/ext/builder.rb does: make_program = ENV['make'] unless make_program then make_program = (/mswin/ =~ RUBY_PLATFORM) ? 'nmake' : 'make' end I believe they should be the same, and that the mkmf.rb method is preferable. ---------------------------------------------------------------------- >Comment By: Luis Lavena (luislavena) Date: 2010-12-31 22:32 Message: Hello, What mkmf with_config does is parse Ruby own configure arguments RbConfig::CONFIG['configure_args'] and extract them. A trivial approach was added, but I'm worry that will break other stuff. The commit is 4bb1149: https://github.com/rubygems/rubygems/commit/4bb1149d10a95ec8c33de1ebaf4b90ce11d0cbee Please verify that works as expected under your environment and report it back. Closing this now, please send a comment to let us know the results. Thank you for your report and happy new year! ---------------------------------------------------------------------- Comment By: James Tucker (raggi) Date: 2010-07-18 09:23 Message: +1 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28399&group_id=126 From noreply at rubyforge.org Fri Dec 31 20:34:52 2010 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 31 Dec 2010 20:34:52 -0500 (EST) Subject: [Rubygems-developers] [ rubygems-Bugs-28744 ] setup.rb fails on 1.9.2 Message-ID: <20110101013452.6A7161858357@rubyforge.org> Bugs item #28744, was opened at 2010-11-22 22:38 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28744&group_id=126 Category: RubyGems installer (setup.rb) Group: next >Status: Closed >Resolution: Rejected Priority: 3 Submitted By: Erik Hollensbe (erikh) Assigned to: Nobody (None) Summary: setup.rb fails on 1.9.2 Initial Comment: https://gist.github.com/190251852fbe20370543 This is the error as found as late as commit 81cd69180a067d638d10cd88099015e3408a5ec0. The problem is that rubygems cannibalizes on its own setup_command for setup.rb, which in turn gets required by gem_prelude and this error shows up. Something along these lines will massage it through, but then all gem commands fail once it's installed: https://gist.github.com/b74973ec7a7418655797 If you dig further you'll find that any attempt for rubygems/custom_require, as provided by prelude, will raise this issue. Overriding it with lib/rubygems/custom_require was something I tried, and didn't get very far. Maybe some of you guys with more domain knowledge can help. I can provide a full image of my patches (which are not pretty and may incite anger, rage, and politics, as they almost completely eliminate prelude from being useful) if so desired, as once down this rabbit hole there be dragons. Thanks, -Erik ---------------------------------------------------------------------- >Comment By: Luis Lavena (luislavena) Date: 2010-12-31 22:34 Message: Hello, Closing this out as the issue is inside Ruby's gem-prelude and can't be fixed in standalone RubyGems. We are pretty aware of this issue but there is no easy solution. Manual installation of RubyGems on top of Ruby 1.9.x is discouraged until that issue is solved in Ruby. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28744&group_id=126 From noreply at rubyforge.org Fri Dec 31 20:40:13 2010 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 31 Dec 2010 20:40:13 -0500 (EST) Subject: [Rubygems-developers] [ rubygems-Bugs-28759 ] Print message when no gems matching your platform are found, or could not be installed Message-ID: <20110101014015.A37D1167831A@rubyforge.org> Bugs item #28759, was opened at 2010-11-30 16:22 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28759&group_id=126 Category: `gem install` command Group: None >Status: Closed >Resolution: Rejected Priority: 3 Submitted By: Greg Hazel (ghazel) >Assigned to: Luis Lavena (luislavena) Summary: Print message when no gems matching your platform are found, or could not be installed Initial Comment: reopening: http://rubyforge.org/tracker/?func=detail&atid=575&aid=21325&group_id=126 Example of the problem today: $ uname -a Linux hostname 2.6.21.7-2.fc8xen #1 SMP Fri Feb 15 12:34:28 EST 2008 x86_64 x86_64 x86_64 GNU/Linux $ sudo gem search -r nokogiri *** REMOTE GEMS *** glebm-nokogiri (1.4.2.1) jwagener-nokogiri (1.4.1) nokogiri (1.4.4.1, 1.4.4, 1.2.3) nokogiri-diff (0.1.0) nokogiri-happymapper (0.3.4) nokogiri-plist (0.3.1) nokogiri-pretty (0.1.0) revo-nokogiri (1.4.1) rsolr-nokogiri (0.0.0) rubyjedi-nokogiri_java (1.4.0.20100513161003) superfeedr-nokogiri (1.4.0.20091116183308) $ sudo gem install nokogiri --version ">= 1.4.4.1" ERROR: could not find gem nokogiri locally or in a repository ---------------------------------------------------------------------- >Comment By: Luis Lavena (luislavena) Date: 2010-12-31 22:40 Message: Hello, As Eric reported, RubyGems 1.3.7 already reports information about the platform the gems versions provide: >gem search -r nokogiri *** REMOTE GEMS *** glebm-nokogiri (1.4.2.1) jwagener-nokogiri (1.4.1) nokogiri (1.4.4.2 java, 1.4.4.1 x86-mingw32 x86-mswin32, 1.4.4, 1.2.3 x86-mswin32-60) nokogiri-diff (0.1.0) nokogiri-happymapper (0.3.6) nokogiri-plist (0.3.1) nokogiri-pretty (0.1.0) revo-nokogiri (1.4.1 java) rsolr-nokogiri (0.0.0) rubyjedi-nokogiri_java (1.4.0.20100513161003 java) superfeedr-nokogiri (1.4.0.20091116183308) The issue specifically you're facing here is more an issue of gem distribution (the gem author) than RubyGems message. A more informative message will not help, you will still not get what you want. Either way, a more informative message could only happen on a newer version of RubyGems, which seems you can't or wan't to update. If you have a suggestion for the error message, even better, a patch, will be highly welcome. Regards. ---------------------------------------------------------------------- Comment By: Greg Hazel (ghazel) Date: 2010-12-01 14:37 Message: I have gem 1.3.5 where that information is not listed. How hard is a more informative error message? ---------------------------------------------------------------------- Comment By: Eric Hodel (drbrain) Date: 2010-12-01 14:34 Message: Note: $ gem env version 1.3.7 ---------------------------------------------------------------------- Comment By: Eric Hodel (drbrain) Date: 2010-12-01 14:33 Message: Why would you try to install nokogiri for windows on purpose when it is clearly listed as such in `gem search`? $ gem search -r nokogiri *** REMOTE GEMS *** glebm-nokogiri (1.4.2.1) jwagener-nokogiri (1.4.1) nokogiri (1.4.4.1 x86-mingw32 x86-mswin32, 1.4.4 ruby java, 1.2.3 x86-mswin32-60) nokogiri-diff (0.1.0) nokogiri-happymapper (0.3.4) nokogiri-plist (0.3.1) nokogiri-pretty (0.1.0) revo-nokogiri (1.4.1 java) rsolr-nokogiri (0.0.0) rubyjedi-nokogiri_java (1.4.0.20100513161003 java) superfeedr-nokogiri (1.4.0.20091116183308) ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28759&group_id=126 From noreply at rubyforge.org Fri Dec 31 21:17:14 2010 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 31 Dec 2010 21:17:14 -0500 (EST) Subject: [Rubygems-developers] [ rubygems-Bugs-28746 ] gem install complains of frozen filename on 1.8.7-p302 Message-ID: <20110101021714.DDE0F1858356@rubyforge.org> Bugs item #28746, was opened at 2010-11-23 01:39 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28746&group_id=126 Category: `gem install` command Group: next >Status: Closed Resolution: None Priority: 3 Submitted By: Erik Hollensbe (erikh) Assigned to: Luis Lavena (luislavena) Summary: gem install complains of frozen filename on 1.8.7-p302 Initial Comment: This patch solves this issue, although it may not be satisfactory. Best I can tell this is not a gems issue but a side-effect of it using optparse. https://gist.github.com/b50b26a6e5cc2124ffee ---------------------------------------------------------------------- >Comment By: Erik Hollensbe (erikh) Date: 2010-12-31 18:17 Message: I don't remember! It was gem build but this feels like an eternity since I reported it. Anyhow, I'll just close it. ---------------------------------------------------------------------- Comment By: Luis Lavena (luislavena) Date: 2010-12-31 15:23 Message: Hello Eric, Can you provide more information about gem install issues? which gems this happens? which version of Ruby? Try to include the whole "gem env" information to help us debug this issue. I've been using p302 for quite some time and never encountered this issue. Thank you. ---------------------------------------------------------------------- Comment By: Erik Hollensbe (erikh) Date: 2010-11-23 01:39 Message: gem build... gah! sorry. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28746&group_id=126 From ryand-ruby at zenspider.com Fri Dec 31 21:34:49 2010 From: ryand-ruby at zenspider.com (Ryan Davis) Date: Fri, 31 Dec 2010 18:34:49 -0800 Subject: [Rubygems-developers] [ANN] rubygems 1.4.0 Released In-Reply-To: <3E51CD6B-5C62-487C-B71F-347E07AA8242@zenspider.com> References: <3E51CD6B-5C62-487C-B71F-347E07AA8242@zenspider.com> Message-ID: <9D61B0F0-3E97-4D7F-8ADA-A121FC181E18@zenspider.com> aaaaaaand another release... (technically, 1.4.0 was released yesterday, but I didn't get around to announcing it until today.) rubygems version 1.4.1 has been released, hot on the tails of 1.4.0! * * * * 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.4.1 / 2010-12-31 Since apparently nobody reads my emails, blog posts or the README: DO NOT UPDATE RUBYGEMS ON RUBY 1.9! See UPGRADING.rdoc for details. Bug fix: * Specification#load was untainting a frozen string (via `gem build *.spec`)