From noreply at rubyforge.org Wed Jun 1 00:17:49 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 1 Jun 2011 00:17:49 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-28454 ] gem install --development installs transitive development dependencies Message-ID: <20110601041749.1C9BE185836C@rubyforge.org> Bugs item #28454, was opened at 2010-08-07 14:49 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28454&group_id=126 Category: None Group: None >Status: Closed Resolution: Accepted Priority: 3 Submitted By: Roger Pack (rogerdpack) >Assigned to: Evan Phoenix (evan) Summary: gem install --development installs transitive development dependencies Initial Comment: Currently it appears that if you install a gem with --development, it installs not only its development dependencies, and also its development dependencies' development dependencies (not just runtime). This results in a failure, for example not being able to use $ jruby -S gem install sensible-cinema --development because though all of its development dependencies are jruby friendly, their respective development dependencies are not, and it ends up trying to build binary extensions which don't work, since this is C, but they are for gems that aren't actual development dependencies for sensible-cinema, so I don't need them anyway. This prevents --development from being useful in this situation. Suggestion: only install development dependencies' run-time dependencies if --development is passed. Thanks. -r ---------------------------------------------------------------------- >Comment By: Evan Phoenix (evan) Date: 2011-06-01 04:17 Message: I've added --dev-shallow which will restrict installing dev deps to the first level only. This might become the default in the future. Added in github:e9ce81e ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28454&group_id=126 From noreply at rubyforge.org Wed Jun 1 00:30:08 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 1 Jun 2011 00:30:08 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-28454 ] gem install --development installs transitive development dependencies Message-ID: <20110601043009.10D45185836C@rubyforge.org> Bugs item #28454, was opened at 2010-08-07 14:49 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28454&group_id=126 Category: None Group: None Status: Closed Resolution: Accepted Priority: 3 Submitted By: Roger Pack (rogerdpack) Assigned to: Evan Phoenix (evan) Summary: gem install --development installs transitive development dependencies Initial Comment: Currently it appears that if you install a gem with --development, it installs not only its development dependencies, and also its development dependencies' development dependencies (not just runtime). This results in a failure, for example not being able to use $ jruby -S gem install sensible-cinema --development because though all of its development dependencies are jruby friendly, their respective development dependencies are not, and it ends up trying to build binary extensions which don't work, since this is C, but they are for gems that aren't actual development dependencies for sensible-cinema, so I don't need them anyway. This prevents --development from being useful in this situation. Suggestion: only install development dependencies' run-time dependencies if --development is passed. Thanks. -r ---------------------------------------------------------------------- >Comment By: Evan Phoenix (evan) Date: 2011-06-01 04:30 Message: shallow is the default behavior in > 1.8.5 ---------------------------------------------------------------------- Comment By: Evan Phoenix (evan) Date: 2011-06-01 04:17 Message: I've added --dev-shallow which will restrict installing dev deps to the first level only. This might become the default in the future. Added in github:e9ce81e ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28454&group_id=126 From noreply at rubyforge.org Wed Jun 1 02:26:18 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 1 Jun 2011 02:26:18 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29168 ] gem install gem_name gives vague error when not connected to network Message-ID: <20110601062618.E9E791678328@rubyforge.org> Bugs item #29168, was opened at 2011-05-05 16:46 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29168&group_id=126 Category: None Group: None >Status: Closed Resolution: None Priority: 3 Submitted By: Bala Paranj (bparanj) Assigned to: Evan Phoenix (evan) Summary: gem install gem_name gives vague error when not connected to network Initial Comment: Example: $ gem install heroku ERROR: http://gems.rubyforge.org/ does not appear to be a repository ERROR: Could not find a valid gem 'heroku' (>= 0) in any repository Here is the code that can be used in the patch to handle different scenarios to give user useful feedback to recover from error: rescue SocketError => serror puts "You are not connected to the network." rescue Errno::ECONNREFUSED => cerror puts "Server is down" rescue => e puts "Exception #{e.message} occurred" end ---------------------------------------------------------------------- >Comment By: Evan Phoenix (evan) Date: 2011-06-01 06:26 Message: I've bulked up the code around talking to sources to better report errors of this sort. You should now get a nice error about not being able to talk to the source. Fixed in github:c041cc5 ---------------------------------------------------------------------- Comment By: Bala Paranj (bparanj) Date: 2011-05-05 17:18 Message: With rubygems 1.8, When I run : gem install heroku : ERROR: Could not find a valid gem 'heroku' (>= 0) in any repository ERROR: Possible alternatives: engine_yard ---------------------------------------------------------------------- Comment By: Bala Paranj (bparanj) Date: 2011-05-05 17:14 Message: Sorry the original report was for 1.3.7. Testing for 1.8 now. ---------------------------------------------------------------------- Comment By: Bala Paranj (bparanj) Date: 2011-05-05 17:11 Message: One more scenario: When you are connected to a public network and you have not agreed to the terms and conditions, it throws "Zlib error". Nice to have message : "Are you at Starbucks? You have not agreed to the terms and conditions." ---------------------------------------------------------------------- Comment By: Evan Phoenix (evan) Date: 2011-05-05 16:58 Message: Please check again with Rubygems 1.8. I'm currently getting an error report like: ERROR: Could not find a valid gem 'blah' (>= 0) in any repository ERROR: While executing gem ... (Gem::RemoteFetcher::FetchError) SocketError: getaddrinfo: nodename nor servname provided, or not known (http://gems.rubyforge9999.org/latest_specs.4.8.gz) ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29168&group_id=126 From noreply at rubyforge.org Wed Jun 1 02:53:01 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 1 Jun 2011 02:53:01 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29116 ] Mega slowness in custom require Message-ID: <20110601065302.05D36185836C@rubyforge.org> Bugs item #29116, was opened at 2011-04-05 18:01 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29116&group_id=126 Category: #gem and #require methods Group: None Status: Open Resolution: None Priority: 3 Submitted By: Sam Goldstein (samgoldstein) Assigned to: Ryan Davis (zenspider) Summary: Mega slowness in custom require Initial Comment: I recently upgraded to rubygems 1.6.5 and started experiencing a major slowdown loading the environment for a Rails 2.3 application. I traced the problem back to the Kernel.require (custom_require.rb) and Gem.loaded_path?. It seems that searching $LOADED_FEATURES repeatedly is inefficient and results in a 4x slowdown in my specific case. I've downgraded to rubygems 1.3.5 which doesn't suffer from this problem. This is a major hurdle to developing in ruby, as it takes me ~45 seconds to load the environment and run one test. Below is some console output demonstrating the problem. /www/aboutus/app_root [master] $ time rake environment (in /www/aboutus/app_root) real 0m11.407s user 0m8.787s sys 0m2.552s /www/aboutus/app_root [master] $ sudo gem update --system Updating RubyGems Updating rubygems-update Successfully installed rubygems-update-1.7.1 Updating RubyGems to 1.7.1 Installing RubyGems 1.7.1 RubyGems 1.7.1 installed === 1.7.1 / 2011-03-32 * 1 bug fix: * Fixed missing file in Manifest.txt. (Also a bug in hoe was fixed where `rake check_manifest` showing a diff would not exit with an error.) ------------------------------------------------------------------------------ RubyGems installed the following executables: /usr/local/bin/gem /www/aboutus/app_root [master] $ time rake environment (in /www/aboutus/app_root) NOTE: SourceIndex.new(hash) is deprecated; From /www/aboutus/app_root/config/../vendor/rails/railties/lib/rails/vendor_gem_source_index.rb:100:in `new'. real 0m46.707s user 0m41.200s sys 0m5.394s Thanks! ---------------------------------------------------------------------- >Comment By: Evan Phoenix (evan) Date: 2011-06-01 06:53 Message: I've moved the regexp creation outside the find block. Could someone who's seeing the issue report back how much of a difference it made? ---------------------------------------------------------------------- Comment By: Nick Rogers (tsp435cds) Date: 2011-05-30 21:47 Message: I am experiencing the same problem with my rails 2.3.11 application, recently upgraded from rubygems 1.3.7 to 1.7.2. Time to initialize rails is an abysmal average of 30s instead of 5s, and I use only a handful of gems. ~/rxg/console: rake gems (in /Users/nick/rxg/console) - [F] attr_encrypted - [F] eigenclass >= 1.1.1 - [F] encryptor >= 1.1.0 - [F] mocha >= 0.9.8 - [R] rake - [F] log4r - [F] netaddr - [F] ntp - [F] hoe >= 1.2.0 - [F] rubyforge >= 2.0.4 - [R] json_pure >= 1.1.7 - [R] rake >= 0.8.7 - [F] SystemTimer - [F] rack - [F] savon - [F] builder >= 2.1.2 - [F] crack >= 0.1.4 - [F] surpass I = Installed F = Frozen R = Framework (loaded before rails starts) ~/rxg/console: I concur that the problem is with custom_require, specifically Gem#loaded_path? and possibly elsewhere. Glancing at rubygems.rb, there are a number of careless instances of what should be loop invariant variables being re-computed within a loop. For example, the following change yielded a 50% performance increase to my rails app load time, however it was still not as good as under rubygems 1.3.7. *** rubygems-1.7.2-original/lib/rubygems.rb 2011-04-05 16:59:14.000000000 -0400 --- rubygems-1.7.2/lib/rubygems.rb 2011-05-30 17:20:56.000000000 -0400 *************** *** 1086,1093 **** def self.loaded_path? path # TODO: ruby needs a feature to let us query what's loaded in 1.8 and 1.9 $LOADED_FEATURES.find { |s| ! s =~ /(^|\/)#{Regexp.escape path}#{Regexp.union(*Gem.suffixes)}$/ } end --- 1086,1095 ---- def self.loaded_path? path # TODO: ruby needs a feature to let us query what's loaded in 1.8 and 1.9 + escaped_path = Regexp.escape(path) + union_suffixes = Regexp.union(*Gem.suffixes) $LOADED_FEATURES.find { |s| ! s =~ /(^|\/)#{escaped_path}#{union_suffixes}$/ } end ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-05-24 00:32 Message: More data, this time with a bit more cleanup and working against rails 2.3.12 (coming RSN) so that deprecations are cleaned up: repo=before-clean repo=after-clean number of gems: 280 number of gems: 175 1.3.7 real 0m2.113s real 0m1.901s user 0m1.762s user 0m1.582s sys 0m0.339s sys 0m0.314s 1.7.2 real 0m7.269s real 0m1.639s user 0m6.836s user 0m1.405s sys 0m0.417s sys 0m0.222s 1.8.2 real 0m7.947s real 0m1.920s user 0m7.488s user 0m1.680s sys 0m0.413s sys 0m0.228s Kinda scary how much those 105 gems affect stuff. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-05-23 23:47 Message: Much of this slowdown occurred as a result of us fixing complex gem dependency resolution bugs. Unfortunately, we're not in a good place to do too much to address this issue right now. I will point out that in both old (< 1.4) rubygems and newer, that the time is going to be proportional to the amount of gems installed. Keeping around a bunch of old stuff you're not using will only harm you in any version. I did get a repro using MOST of what Sam reported. I couldn't install some gems because I didn't have requisite libraries (eg I never use mysql, so it couldn't build) and some of his gems are not in the main gem repo. Of his 287 gems (WOW!) I was able to install 273 of them. Until I tried out a rails app, EVERY timing I tried to do wound up at least 25% faster in 1.7/1.8 over 1.3.7. Once we got to really complex graphs of activation (read: rails), I was able to get a repro where 1.7/1.8 was slower. I got the following times while loading a rails 2.3.4 config/environment.rb file: repo=xxx; before 'gem clean' number of gems: 273 1.3.7 real 0m1.492s user 0m1.230s sys 0m0.256s 1.7.2 real 0m3.533s user 0m3.281s sys 0m0.242s 1.8.2 real 0m3.998s user 0m3.731s sys 0m0.261s I copied that repo and ran gem clean on it (and reinstalled rails 2.3.4 because rails 3 wiped it out on cleanup!) and got the following MUCH better times: repo=yyy; after 'gem clean' number of gems: 183 1.3.7 real 0m1.288s user 0m1.054s sys 0m0.231s 1.7.2 real 0m1.106s user 0m0.932s sys 0m0.169s 1.8.2 real 0m1.365s user 0m1.181s sys 0m0.179s So... that's the workaround for now. I'll do what I can to profile and optimize, but I can't promise much for the next release, partially because we don't have enough test coverage on this aspect of rubygems. ---------------------------------------------------------------------- Comment By: Dan Peterson (dpiddy) Date: 2011-05-23 15:20 Message: This is still happening in 1.8.3. ---------------------------------------------------------------------- Comment By: Dan Peterson (dpiddy) Date: 2011-05-05 01:42 Message: I have seen this as well for something non-Rails. Using `rvm rubygems` I saw the slowness started with 1.6.0. Haven't had a chance to really dig into it more yet. ---------------------------------------------------------------------- Comment By: Sam Goldstein (samgoldstein) Date: 2011-04-05 18:07 Message: More info on gem dependencies and installed gems. $ rake gems (in /www/aboutus/compostus/compost) - [F] thrift_client ~> 0.4.3 - [I] thrift - [I] thrift = 0.2.0.4 - [F] simple_uuid = 0.1.1 - [F] cassandra = 0.8.2 - [F] thrift_client >= 0.4.0 - [I] thrift - [I] json - [R] rake - [F] simple_uuid >= 0.1.0 - [F] rack ~> 1.0.0 - [F] diff-lcs = 1.1.2 - [I] ffi ~> 0.6.0 - [R] rake >= 0.8.7 - [F] haml - [I] libxml-ruby - [I] hpricot >= 0.8.1 - [I] json - [I] mysql = 2.8.1 - [F] net-ssh - [F] ya2yaml = 0.26 - [F] ruby-openid = 2.1.6 - [F] mechanize = 1.0.0 - [I] nokogiri >= 1.2.1 - [I] nokogiri - [F] composite_primary_keys = 2.2.2 - [R] activerecord >= 2.2.0 - [F] aws-s3 = 0.6.2 - [F] xml-simple - [F] builder - [F] mime-types - [F] right_aws - [F] right_http_connection >= 1.2.4 - [F] fastercsv = 1.5.0 - [I] levenshtein - [F] newrelic_rpm = 2.13.4 - [F] after_commit ~> 1.0.7 - [R] activerecord - [F] less = 1.2.21 - [F] treetop >= 1.4.2 - [F] polyglot >= 0.3.1 - [F] mutter >= 0.4.2 - [F] treetop = 1.4.8 - [F] polyglot >= 0.3.1 - [F] mime-types = 1.16 - [I] curb = 0.7.8 I = Installed F = Frozen R = Framework (loaded before rails starts) $ gem list abstract (1.0.0) actionmailer (3.0.5, 3.0.3, 2.3.4, 2.2.2) actionpack (3.0.5, 3.0.3, 2.3.4, 2.2.2) activemodel (3.0.5, 3.0.3) activerecord (3.0.5, 3.0.3, 2.3.4, 2.2.2) activeresource (3.0.5, 3.0.3, 2.3.4, 2.2.2) activesupport (3.0.5, 3.0.3, 2.3.11, 2.3.8, 2.3.7, 2.3.5, 2.3.4, 2.2.2) acts_as_commentable (3.0.1, 2.0.2) addressable (2.2.4) after_commit (1.0.7, 1.0.5) amatch (0.2.3) amazon_sdb (0.6.7) amqp (0.6.0) ar-extensions (0.8.0) arel (2.0.9, 2.0.8) au_document_parser (0.5.3, 0.4.3, 0.4.2, 0.4.1, 0.4.0, 0.3.2, 0.3.1, 0.3.0, 0.2.4) autotest-growl (0.1.7) aws-s3 (0.6.2) babel (0.1.4) builder (2.1.2) bundler (1.0.10) capistrano (2.5.5) capybara (0.3.0) carmen (0.2.5) cassandra (0.7.2, 0.6) cgi_multipart_eof_fix (2.5.0) cheat (1.2.1) chronic (0.3.0, 0.2.3) clearance (0.10.3.2, 0.8.8, 0.8.3) compass (0.8.17) compass-960-plugin (0.9.11) composite_primary_keys (2.2.2) configuration (1.1.0) crack (0.1.4) cucumber (0.10.2, 0.6.3, 0.6.2) cucumber-rails (0.3.2, 0.2.4, 0.2.3) culerity (0.2.6) curb (0.7.8, 0.7.7.1, 0.7.1) daemons (1.0.10) database_cleaner (0.4.3) diesel (0.1.4) diff-lcs (1.1.2) differ (0.1.1) diffy (2.0.1) dirb (1.0.0, 0.1.1, 0.1.0) duration (0.1.0) erubis (2.6.6) eventmachine (0.12.10) factory_girl (1.2.3) fakefs (0.2.1) faker (0.3.1) faraday (0.5.7) fastercsv (1.5.0) fastthread (1.0.7) ffi (0.6.3, 0.5.4, 0.5.3) file-tail (1.0.4) fixjour (0.1.6) flexmock (0.8.6) gem_plugin (0.2.3) gemcutter (0.5.0) geminstaller (0.5.4) geokit (1.5.0) getopt-declare (1.28) gherkin (2.3.5) git (1.2.5) gltail (0.1.8) gravatar (1.0) grit (2.0.0, 1.1.1) haml (3.0.25, 3.0.13, 2.2.19, 2.2.9) heroku (1.9.8) highline (1.5.1) hoe (2.3.3) hpricot (0.8.1) httparty (0.5.0) i18n (0.5.0) icalendar (1.1.2, 1.1.0) jeweler (1.4.0) jm81-whois (0.5.0) json (1.4.6, 1.2.0, 1.1.6) json_pure (1.2.0) launchy (0.3.3) less (1.2.21) levenshtein (0.2.0) libxml-ruby (1.1.3) log4r (1.1.9) lorem (0.1.2) macaddr (1.0.0) mail (2.2.15, 1.5.2) maruku (0.6.0) mechanize (1.0.0, 0.9.3) memcache-client (1.7.4) micronaut (0.3.0) mime-types (1.16) mkrf (0.2.3) mocha (0.9.8) mongrel (1.1.5) more (0.1.1) multi_json (0.0.5) multipart-post (1.1.0) mutter (0.5.3) mysql (2.8.1) needle (1.3.0) net-scp (1.0.2) net-sftp (2.0.4, 1.1.0) net-ssh (2.0.15, 1.1.4, 1.0.10) net-ssh-gateway (1.0.1) newrelic_rpm (2.14.0, 2.9.9, 2.9.8, 2.9.3) nkallen-cache-money (0.2.5) nokogiri (1.4.0) open4 (1.0.1) paperclip (2.3.1.1) parseexcel (0.5.2) polyglot (0.3.1, 0.3.0, 0.2.9) rack (1.2.2, 1.2.1, 1.0.1) rack-mount (0.6.14, 0.6.13) rack-rewrite (1.0.2) rack-test (0.5.7, 0.5.3) rails (3.0.5, 3.0.3, 2.3.4, 2.2.2) railties (3.0.5, 3.0.3) rake (0.8.7, 0.8.3) rcov (0.9.6) RedCloth (4.2.2) redis (2.1.1) redis-namespace (0.10.0) resque (1.13.0) rest-client (1.4.2) riddle (1.0.11, 1.0.8) right_aws (1.10.0) right_http_connection (1.2.4) rpx_now (0.6.11) rspec (2.5.0, 1.3.0, 1.2.9, 1.2.7) rspec-core (2.5.1) rspec-expectations (2.5.0) rspec-mocks (2.5.0) rspec-rails (2.5.0, 1.3.2, 1.2.9, 1.2.7) ruby-aws (1.2.0) ruby-graphviz (0.9.21) ruby-ole (1.2.10.1) ruby-opengl (0.60.1) ruby-openid (2.1.6) ruby-prof (0.9.2, 0.8.1) rubyforge (2.0.4, 2.0.3) rubygems-update (1.7.1, 1.6.2) RubyInline (3.8.1) rufus-tokyo (0.1.14) rvm (0.0.98) selenium-webdriver (0.0.14) sequel (3.14.0, 3.9.0, 3.6.0) simple_uuid (0.0.2) sinatra (1.2.1, 1.1.2, 1.0, 0.9.5) slave (1.2.1) smurf (1.0.3) snailgun (1.0.6) spork (0.7.5) spreadsheet (0.6.4.1) sqlite3 (1.3.3) sqlite3-ruby (1.3.3, 1.2.5) stemmer (1.0.1) syntax (1.0.0) technicalpickles-jeweler (1.2.1) term-ansicolor (1.0.5, 1.0.4) Text (1.1.2) thinking-sphinx (1.3.18, 1.3.14) thor (0.14.6) thoughtbot-factory_girl (1.2.2) thrift (0.2.0.4) thrift_client (0.3.3, 0.3.1) tilt (1.2.2) timetrap (1.7.4, 1.4.0, 1.3.0, 1.2.1, 1.2.0, 1.1.3, 1.1.2) treetop (1.4.9, 1.4.8, 1.4.2) tzinfo (0.3.26, 0.3.25, 0.3.24) uuid (2.1.0, 2.0.1) uuidtools (2.1.2, 2.1.1) vegas (0.1.8) vlad (1.3.2) webrat (0.7.0, 0.6.0, 0.4.4) will_paginate (2.3.11) xhtmldiff (1.0.0) xml-simple (1.0.14, 1.0.12) xmpp4r (0.4) ya2yaml (0.26) ZenTest (4.1.4) ---------------------------------------------------------------------- Comment By: Sam Goldstein (samgoldstein) Date: 2011-04-05 18:02 Message: BTW the first environment load was with gem version 1.3.5 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29116&group_id=126 From noreply at rubyforge.org Wed Jun 1 03:03:27 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 1 Jun 2011 03:03:27 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-28491 ] fetch a specific prerelease version Message-ID: <20110601070327.AA7A8185836C@rubyforge.org> Bugs item #28491, was opened at 2010-08-19 22:30 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28491&group_id=126 Category: `gem` commands (remote behavior) Group: v1.3.x >Status: Closed Resolution: None Priority: 3 Submitted By: gabriel horner (cldwalker) >Assigned to: Evan Phoenix (evan) Summary: fetch a specific prerelease version Initial Comment: I can't fetch a specific prerelease version: $ gem fetch dm-core -v '1.0.0.rc2' --pre --debug Exception `NameError' at /Users/bozo/.rvm/rubies/ruby-1.8.7-p299/lib/ruby/site_ruby/1.8/rubygems/command_manager.rb:164 - uninitialized constant Gem::Commands::FetchCommand Exception `OptionParser::InvalidOption' at /Users/bozo/.rvm/rubies/ruby-1.8.7-p299/lib/ruby/1.8/optparse.rb:1450 - invalid option: no-ri Exception `OptionParser::InvalidOption' at /Users/bozo/.rvm/rubies/ruby-1.8.7-p299/lib/ruby/1.8/optparse.rb:1263 - invalid option: --no-ri ERROR: Could not find a valid gem 'dm-core' (= 1.0.0.rc2) in any repository I'm aware I can fetch the latest prerelease version: gem fetch dm-core --pre but I need specific prerelease versions of gems. Is this possible? FYI, I originally asked about this on help.rubygems.org: http://help.rubygems.org/discussions/questions/38-gem-fetch-a-specific-prerelease-version My gem environment: $ gem env RubyGems Environment: - RUBYGEMS VERSION: 1.3.7 - RUBY VERSION: 1.8.7 (2010-06-23 patchlevel 299) [i686-darwin9.4.0] - INSTALLATION DIRECTORY: /Users/bozo/.rvm/gems/ruby-1.8.7-p299 at ext - RUBY EXECUTABLE: /Users/bozo/.rvm/rubies/ruby-1.8.7-p299/bin/ruby - EXECUTABLE DIRECTORY: /Users/bozo/.rvm/gems/ruby-1.8.7-p299 at ext/bin - RUBYGEMS PLATFORMS: - ruby - x86-darwin-9 - GEM PATHS: - /Users/bozo/.rvm/gems/ruby-1.8.7-p299 at ext - /Users/bozo/.rvm/gems/ruby-1.8.7-p299 at global - GEM CONFIGURATION: - :update_sources => true - :verbose => true - :benchmark => false - :backtrace => false - :bulk_threshold => 1000 - "gem" => "--no-ri" - :sources => ["http://rubygems.org"] - REMOTE SOURCES: - http://rubygems.org ---------------------------------------------------------------------- >Comment By: Evan Phoenix (evan) Date: 2011-06-01 07:03 Message: Fixed in github:040d8d4 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28491&group_id=126 From noreply at rubyforge.org Wed Jun 1 03:06:42 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 1 Jun 2011 03:06:42 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-28481 ] 'gem install' always prefers local files with partial name match Message-ID: <20110601070642.E22C5185836C@rubyforge.org> Bugs item #28481, was opened at 2010-08-17 12:21 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28481&group_id=126 Category: `gem install` command Group: v1.3.x >Status: Closed Resolution: Accepted Priority: 3 Submitted By: Hirotsugu Asari (asarih) >Assigned to: Evan Phoenix (evan) Summary: 'gem install' always prefers local files with partial name match Initial Comment: If you try to install gem with a shorter name (e.g., active_form) from a remote server but you have a .gem file of another gem with a longer name (e.g., active_forms) in the working directory, 'gem install' will use the gem file. The exact match should be preferred. $ ruby -v -S gem install --ignore-dependencies --no-rdoc --no-ri active_forms-0.2.1.gem ruby 1.8.7 (2010-06-23 patchlevel 299) [i686-darwin10.4.0] Successfully installed active_forms-0.2.1 1 gem installed $ ruby -v -S gem install --ignore-dependencies --no-rdoc --no-ri active_form ruby 1.8.7 (2010-06-23 patchlevel 299) [i686-darwin10.4.0] Successfully installed active_forms-0.2.1 1 gem installed This was first reported by Stephen Bannasch in http://jira.codehaus.org/browse/JRUBY-4934. ---------------------------------------------------------------------- >Comment By: Evan Phoenix (evan) Date: 2011-06-01 07:06 Message: This is related to gem's default behavior of checking for .gem files first by default. If -r is specified, it will only consider remote sources. The bug #26109 was also fixed, which should clear up the situation. ---------------------------------------------------------------------- Comment By: Christof Spies (wingfire) Date: 2010-08-20 06:59 Message: seams to be the same bug as #26109 http://rubyforge.org/tracker/index.php?func=detail&aid=26109&group_id=126&atid=575 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28481&group_id=126 From noreply at rubyforge.org Wed Jun 1 03:31:59 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 1 Jun 2011 03:31:59 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29059 ] 1.6.1 doesn't update prerelease gems Message-ID: <20110601073159.A7B841858372@rubyforge.org> Bugs item #29059, was opened at 2011-03-04 15:08 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29059&group_id=126 Category: `gem` commands (other) Group: v1.6.x >Status: Closed Resolution: None Priority: 3 Submitted By: Jon Forums (jonforums) >Assigned to: Evan Phoenix (evan) Summary: 1.6.1 doesn't update prerelease gems Initial Comment: Is this use case supported? C:\Users\Jon>gem list eventmachine *** LOCAL GEMS *** eventmachine (1.0.0.beta.2 x86-mingw32) C:\Users\Jon>gem list eventmachine -r --pre *** REMOTE GEMS *** eventmachine (1.0.0.beta.3 ruby java java x86-mingw32 x86-mingw32 x86-mswin32-60 x86-mswin32-60, 1.0.0.beta.2 ruby java java x86-mingw32 x86-mingw32 x86-mswin32-60 x86-mswin32-60, 1.0.0.beta.1 ruby java java) C:\Users\Jon>gem update eventmachine --pre Updating installed gems Nothing to update C:\Users\Jon>gem env RubyGems Environment: - RUBYGEMS VERSION: 1.6.1 - RUBY VERSION: 1.9.3 (2011-03-04 patchlevel -1) [i386-mingw32] - INSTALLATION DIRECTORY: C:/ruby19trunk/lib/ruby/gems/1.9.1 - RUBY EXECUTABLE: C:/ruby19trunk/bin/ruby.exe - EXECUTABLE DIRECTORY: C:/ruby19trunk/bin - RUBYGEMS PLATFORMS: - ruby - x86-mingw32 - GEM PATHS: - C:/ruby19trunk/lib/ruby/gems/1.9.1 - C:/Users/Jon/.gem/ruby/1.9.1 - GEM CONFIGURATION: - :update_sources => true - :verbose => true - :benchmark => false - :backtrace => false - :bulk_threshold => 1000 - :sources => ["http://rubygems.org", "http://gemcutter.org"] - "gem" => "--no-ri --no-rdoc" - REMOTE SOURCES: - http://rubygems.org - http://gemcutter.org ---------------------------------------------------------------------- >Comment By: Evan Phoenix (evan) Date: 2011-06-01 07:31 Message: Fixed in github:69ab4b9 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29059&group_id=126 From noreply at rubyforge.org Wed Jun 1 03:40:50 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 1 Jun 2011 03:40:50 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29114 ] older gems interfere with loading paths from external gems Message-ID: <20110601074050.91012185836C@rubyforge.org> Bugs item #29114, was opened at 2011-04-05 06:22 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29114&group_id=126 Category: None Group: None >Status: Closed Resolution: None Priority: 3 Submitted By: Daniel DeLeo (danielsdeleo) >Assigned to: Evan Phoenix (evan) Summary: older gems interfere with loading paths from external gems Initial Comment: I'm seeing this issue with the Chef project. In the current release version, we have a bunch of files under chef/knife/whatever.rb In the current prerelease version, we have plugin support using Gem.find_files (thanks for the patch guys!), so we've moved much of this code out to separate gems. We strip the paths we get back from Gem.find_files to the normal relative paths (e.g., chef/knife/ec2_server_create) so that we can uniq them and rely on rubygems to load the latest version of the gem. The problem I'm seeing is this: Chef 0.9.14 has a file 'chef/knife/ec2_instance_data' Chef 0.10.0 does not have this file. the knife-ec2 plugin *does* have a file 'chef/knife/ec2_instance_data' When I have both Chef 0.9.14 and Chef 0.10 installed and Chef 0.10 attempts to `require 'chef/knife/ec2_instance_data'` it gets a LoadError /Users/ddeleo/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:57:in `require': no such file to load -- chef/knife/ec2_instance_data (LoadError) from /Users/ddeleo/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:57:in `rescue in require' from /Users/ddeleo/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:35:in `require' from /Users/ddeleo/.rvm/gems/ruby-1.9.2-p180/gems/chef-0.10.0.beta.6/lib/chef/knife/core/subcommand_loader.rb:39:in `block in load_commands' # etc. If I run `gem which chef/knife/ec2_instance_data`, I see that rubygems prefers the one in the old version of chef: gem which chef/knife/ec2_instance_data /Users/ddeleo/.rvm/gems/ruby-1.9.2-p180/gems/chef-0.9.14/lib/chef/knife/ec2_instance_data.rb When I uninstall the old version of chef, so that I have only the 0.10 beta, then chef 0.10 can successfully require the 'chef/knife/ec2_instance_data' file, and `gem which` reports that the file is located in the knife-ec2 gem. ---------------------------------------------------------------------- >Comment By: Evan Phoenix (evan) Date: 2011-06-01 07:40 Message: This feels like just a configuration error on the machine. The reason rubygems is raising a LoadError is because the path you've given it is ambigious on that system since the file is available via 2 gems (admittedly the error message should be better). Given the scenario, there is really no way for rubygems to work out what course of action to take thusly there is really nothing that we can do it about this, rubygems wise. Forcing the activation of knife-ec2 disambiguates the problem for rubygems and it's happy to then continue. Additionally, removing the old chef disambiguates things and allow it to continue. Because rubygems activates gems via the paths their contain, there is no way to change rubygems to solve this problem. ---------------------------------------------------------------------- Comment By: Daniel DeLeo (danielsdeleo) Date: 2011-04-05 06:27 Message: Forcing activation of the plugin gem (e.g., knife-ec2 in the example) works around the error, though extracting the gem name is messy to say the least. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29114&group_id=126 From noreply at rubyforge.org Wed Jun 1 08:32:10 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 1 Jun 2011 08:32:10 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29116 ] Mega slowness in custom require Message-ID: <20110601123212.429EB1858376@rubyforge.org> Bugs item #29116, was opened at 2011-04-05 15:01 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29116&group_id=126 Category: #gem and #require methods Group: None Status: Open Resolution: None Priority: 3 Submitted By: Sam Goldstein (samgoldstein) Assigned to: Ryan Davis (zenspider) Summary: Mega slowness in custom require Initial Comment: I recently upgraded to rubygems 1.6.5 and started experiencing a major slowdown loading the environment for a Rails 2.3 application. I traced the problem back to the Kernel.require (custom_require.rb) and Gem.loaded_path?. It seems that searching $LOADED_FEATURES repeatedly is inefficient and results in a 4x slowdown in my specific case. I've downgraded to rubygems 1.3.5 which doesn't suffer from this problem. This is a major hurdle to developing in ruby, as it takes me ~45 seconds to load the environment and run one test. Below is some console output demonstrating the problem. /www/aboutus/app_root [master] $ time rake environment (in /www/aboutus/app_root) real 0m11.407s user 0m8.787s sys 0m2.552s /www/aboutus/app_root [master] $ sudo gem update --system Updating RubyGems Updating rubygems-update Successfully installed rubygems-update-1.7.1 Updating RubyGems to 1.7.1 Installing RubyGems 1.7.1 RubyGems 1.7.1 installed === 1.7.1 / 2011-03-32 * 1 bug fix: * Fixed missing file in Manifest.txt. (Also a bug in hoe was fixed where `rake check_manifest` showing a diff would not exit with an error.) ------------------------------------------------------------------------------ RubyGems installed the following executables: /usr/local/bin/gem /www/aboutus/app_root [master] $ time rake environment (in /www/aboutus/app_root) NOTE: SourceIndex.new(hash) is deprecated; From /www/aboutus/app_root/config/../vendor/rails/railties/lib/rails/vendor_gem_source_index.rb:100:in `new'. real 0m46.707s user 0m41.200s sys 0m5.394s Thanks! ---------------------------------------------------------------------- Comment By: Dan Peterson (dpiddy) Date: 2011-06-01 09:31 Message: Here's what my test case looks like with 1.5.2, 1.8.5 and master after Evan's change: # 1.5.2 eye help 1.26s user 0.26s system 99% cpu 1.526 total # 1.8.5 eye help 9.85s user 0.61s system 100% cpu 10.455 total # master eye help 5.44s user 0.51s system 100% cpu 5.947 total ---------------------------------------------------------------------- Comment By: Evan Phoenix (evan) Date: 2011-06-01 03:53 Message: I've moved the regexp creation outside the find block. Could someone who's seeing the issue report back how much of a difference it made? ---------------------------------------------------------------------- Comment By: Nick Rogers (tsp435cds) Date: 2011-05-30 18:47 Message: I am experiencing the same problem with my rails 2.3.11 application, recently upgraded from rubygems 1.3.7 to 1.7.2. Time to initialize rails is an abysmal average of 30s instead of 5s, and I use only a handful of gems. ~/rxg/console: rake gems (in /Users/nick/rxg/console) - [F] attr_encrypted - [F] eigenclass >= 1.1.1 - [F] encryptor >= 1.1.0 - [F] mocha >= 0.9.8 - [R] rake - [F] log4r - [F] netaddr - [F] ntp - [F] hoe >= 1.2.0 - [F] rubyforge >= 2.0.4 - [R] json_pure >= 1.1.7 - [R] rake >= 0.8.7 - [F] SystemTimer - [F] rack - [F] savon - [F] builder >= 2.1.2 - [F] crack >= 0.1.4 - [F] surpass I = Installed F = Frozen R = Framework (loaded before rails starts) ~/rxg/console: I concur that the problem is with custom_require, specifically Gem#loaded_path? and possibly elsewhere. Glancing at rubygems.rb, there are a number of careless instances of what should be loop invariant variables being re-computed within a loop. For example, the following change yielded a 50% performance increase to my rails app load time, however it was still not as good as under rubygems 1.3.7. *** rubygems-1.7.2-original/lib/rubygems.rb 2011-04-05 16:59:14.000000000 -0400 --- rubygems-1.7.2/lib/rubygems.rb 2011-05-30 17:20:56.000000000 -0400 *************** *** 1086,1093 **** def self.loaded_path? path # TODO: ruby needs a feature to let us query what's loaded in 1.8 and 1.9 $LOADED_FEATURES.find { |s| ! s =~ /(^|\/)#{Regexp.escape path}#{Regexp.union(*Gem.suffixes)}$/ } end --- 1086,1095 ---- def self.loaded_path? path # TODO: ruby needs a feature to let us query what's loaded in 1.8 and 1.9 + escaped_path = Regexp.escape(path) + union_suffixes = Regexp.union(*Gem.suffixes) $LOADED_FEATURES.find { |s| ! s =~ /(^|\/)#{escaped_path}#{union_suffixes}$/ } end ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-05-23 21:32 Message: More data, this time with a bit more cleanup and working against rails 2.3.12 (coming RSN) so that deprecations are cleaned up: repo=before-clean repo=after-clean number of gems: 280 number of gems: 175 1.3.7 real 0m2.113s real 0m1.901s user 0m1.762s user 0m1.582s sys 0m0.339s sys 0m0.314s 1.7.2 real 0m7.269s real 0m1.639s user 0m6.836s user 0m1.405s sys 0m0.417s sys 0m0.222s 1.8.2 real 0m7.947s real 0m1.920s user 0m7.488s user 0m1.680s sys 0m0.413s sys 0m0.228s Kinda scary how much those 105 gems affect stuff. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-05-23 20:47 Message: Much of this slowdown occurred as a result of us fixing complex gem dependency resolution bugs. Unfortunately, we're not in a good place to do too much to address this issue right now. I will point out that in both old (< 1.4) rubygems and newer, that the time is going to be proportional to the amount of gems installed. Keeping around a bunch of old stuff you're not using will only harm you in any version. I did get a repro using MOST of what Sam reported. I couldn't install some gems because I didn't have requisite libraries (eg I never use mysql, so it couldn't build) and some of his gems are not in the main gem repo. Of his 287 gems (WOW!) I was able to install 273 of them. Until I tried out a rails app, EVERY timing I tried to do wound up at least 25% faster in 1.7/1.8 over 1.3.7. Once we got to really complex graphs of activation (read: rails), I was able to get a repro where 1.7/1.8 was slower. I got the following times while loading a rails 2.3.4 config/environment.rb file: repo=xxx; before 'gem clean' number of gems: 273 1.3.7 real 0m1.492s user 0m1.230s sys 0m0.256s 1.7.2 real 0m3.533s user 0m3.281s sys 0m0.242s 1.8.2 real 0m3.998s user 0m3.731s sys 0m0.261s I copied that repo and ran gem clean on it (and reinstalled rails 2.3.4 because rails 3 wiped it out on cleanup!) and got the following MUCH better times: repo=yyy; after 'gem clean' number of gems: 183 1.3.7 real 0m1.288s user 0m1.054s sys 0m0.231s 1.7.2 real 0m1.106s user 0m0.932s sys 0m0.169s 1.8.2 real 0m1.365s user 0m1.181s sys 0m0.179s So... that's the workaround for now. I'll do what I can to profile and optimize, but I can't promise much for the next release, partially because we don't have enough test coverage on this aspect of rubygems. ---------------------------------------------------------------------- Comment By: Dan Peterson (dpiddy) Date: 2011-05-23 12:20 Message: This is still happening in 1.8.3. ---------------------------------------------------------------------- Comment By: Dan Peterson (dpiddy) Date: 2011-05-04 22:42 Message: I have seen this as well for something non-Rails. Using `rvm rubygems` I saw the slowness started with 1.6.0. Haven't had a chance to really dig into it more yet. ---------------------------------------------------------------------- Comment By: Sam Goldstein (samgoldstein) Date: 2011-04-05 15:07 Message: More info on gem dependencies and installed gems. $ rake gems (in /www/aboutus/compostus/compost) - [F] thrift_client ~> 0.4.3 - [I] thrift - [I] thrift = 0.2.0.4 - [F] simple_uuid = 0.1.1 - [F] cassandra = 0.8.2 - [F] thrift_client >= 0.4.0 - [I] thrift - [I] json - [R] rake - [F] simple_uuid >= 0.1.0 - [F] rack ~> 1.0.0 - [F] diff-lcs = 1.1.2 - [I] ffi ~> 0.6.0 - [R] rake >= 0.8.7 - [F] haml - [I] libxml-ruby - [I] hpricot >= 0.8.1 - [I] json - [I] mysql = 2.8.1 - [F] net-ssh - [F] ya2yaml = 0.26 - [F] ruby-openid = 2.1.6 - [F] mechanize = 1.0.0 - [I] nokogiri >= 1.2.1 - [I] nokogiri - [F] composite_primary_keys = 2.2.2 - [R] activerecord >= 2.2.0 - [F] aws-s3 = 0.6.2 - [F] xml-simple - [F] builder - [F] mime-types - [F] right_aws - [F] right_http_connection >= 1.2.4 - [F] fastercsv = 1.5.0 - [I] levenshtein - [F] newrelic_rpm = 2.13.4 - [F] after_commit ~> 1.0.7 - [R] activerecord - [F] less = 1.2.21 - [F] treetop >= 1.4.2 - [F] polyglot >= 0.3.1 - [F] mutter >= 0.4.2 - [F] treetop = 1.4.8 - [F] polyglot >= 0.3.1 - [F] mime-types = 1.16 - [I] curb = 0.7.8 I = Installed F = Frozen R = Framework (loaded before rails starts) $ gem list abstract (1.0.0) actionmailer (3.0.5, 3.0.3, 2.3.4, 2.2.2) actionpack (3.0.5, 3.0.3, 2.3.4, 2.2.2) activemodel (3.0.5, 3.0.3) activerecord (3.0.5, 3.0.3, 2.3.4, 2.2.2) activeresource (3.0.5, 3.0.3, 2.3.4, 2.2.2) activesupport (3.0.5, 3.0.3, 2.3.11, 2.3.8, 2.3.7, 2.3.5, 2.3.4, 2.2.2) acts_as_commentable (3.0.1, 2.0.2) addressable (2.2.4) after_commit (1.0.7, 1.0.5) amatch (0.2.3) amazon_sdb (0.6.7) amqp (0.6.0) ar-extensions (0.8.0) arel (2.0.9, 2.0.8) au_document_parser (0.5.3, 0.4.3, 0.4.2, 0.4.1, 0.4.0, 0.3.2, 0.3.1, 0.3.0, 0.2.4) autotest-growl (0.1.7) aws-s3 (0.6.2) babel (0.1.4) builder (2.1.2) bundler (1.0.10) capistrano (2.5.5) capybara (0.3.0) carmen (0.2.5) cassandra (0.7.2, 0.6) cgi_multipart_eof_fix (2.5.0) cheat (1.2.1) chronic (0.3.0, 0.2.3) clearance (0.10.3.2, 0.8.8, 0.8.3) compass (0.8.17) compass-960-plugin (0.9.11) composite_primary_keys (2.2.2) configuration (1.1.0) crack (0.1.4) cucumber (0.10.2, 0.6.3, 0.6.2) cucumber-rails (0.3.2, 0.2.4, 0.2.3) culerity (0.2.6) curb (0.7.8, 0.7.7.1, 0.7.1) daemons (1.0.10) database_cleaner (0.4.3) diesel (0.1.4) diff-lcs (1.1.2) differ (0.1.1) diffy (2.0.1) dirb (1.0.0, 0.1.1, 0.1.0) duration (0.1.0) erubis (2.6.6) eventmachine (0.12.10) factory_girl (1.2.3) fakefs (0.2.1) faker (0.3.1) faraday (0.5.7) fastercsv (1.5.0) fastthread (1.0.7) ffi (0.6.3, 0.5.4, 0.5.3) file-tail (1.0.4) fixjour (0.1.6) flexmock (0.8.6) gem_plugin (0.2.3) gemcutter (0.5.0) geminstaller (0.5.4) geokit (1.5.0) getopt-declare (1.28) gherkin (2.3.5) git (1.2.5) gltail (0.1.8) gravatar (1.0) grit (2.0.0, 1.1.1) haml (3.0.25, 3.0.13, 2.2.19, 2.2.9) heroku (1.9.8) highline (1.5.1) hoe (2.3.3) hpricot (0.8.1) httparty (0.5.0) i18n (0.5.0) icalendar (1.1.2, 1.1.0) jeweler (1.4.0) jm81-whois (0.5.0) json (1.4.6, 1.2.0, 1.1.6) json_pure (1.2.0) launchy (0.3.3) less (1.2.21) levenshtein (0.2.0) libxml-ruby (1.1.3) log4r (1.1.9) lorem (0.1.2) macaddr (1.0.0) mail (2.2.15, 1.5.2) maruku (0.6.0) mechanize (1.0.0, 0.9.3) memcache-client (1.7.4) micronaut (0.3.0) mime-types (1.16) mkrf (0.2.3) mocha (0.9.8) mongrel (1.1.5) more (0.1.1) multi_json (0.0.5) multipart-post (1.1.0) mutter (0.5.3) mysql (2.8.1) needle (1.3.0) net-scp (1.0.2) net-sftp (2.0.4, 1.1.0) net-ssh (2.0.15, 1.1.4, 1.0.10) net-ssh-gateway (1.0.1) newrelic_rpm (2.14.0, 2.9.9, 2.9.8, 2.9.3) nkallen-cache-money (0.2.5) nokogiri (1.4.0) open4 (1.0.1) paperclip (2.3.1.1) parseexcel (0.5.2) polyglot (0.3.1, 0.3.0, 0.2.9) rack (1.2.2, 1.2.1, 1.0.1) rack-mount (0.6.14, 0.6.13) rack-rewrite (1.0.2) rack-test (0.5.7, 0.5.3) rails (3.0.5, 3.0.3, 2.3.4, 2.2.2) railties (3.0.5, 3.0.3) rake (0.8.7, 0.8.3) rcov (0.9.6) RedCloth (4.2.2) redis (2.1.1) redis-namespace (0.10.0) resque (1.13.0) rest-client (1.4.2) riddle (1.0.11, 1.0.8) right_aws (1.10.0) right_http_connection (1.2.4) rpx_now (0.6.11) rspec (2.5.0, 1.3.0, 1.2.9, 1.2.7) rspec-core (2.5.1) rspec-expectations (2.5.0) rspec-mocks (2.5.0) rspec-rails (2.5.0, 1.3.2, 1.2.9, 1.2.7) ruby-aws (1.2.0) ruby-graphviz (0.9.21) ruby-ole (1.2.10.1) ruby-opengl (0.60.1) ruby-openid (2.1.6) ruby-prof (0.9.2, 0.8.1) rubyforge (2.0.4, 2.0.3) rubygems-update (1.7.1, 1.6.2) RubyInline (3.8.1) rufus-tokyo (0.1.14) rvm (0.0.98) selenium-webdriver (0.0.14) sequel (3.14.0, 3.9.0, 3.6.0) simple_uuid (0.0.2) sinatra (1.2.1, 1.1.2, 1.0, 0.9.5) slave (1.2.1) smurf (1.0.3) snailgun (1.0.6) spork (0.7.5) spreadsheet (0.6.4.1) sqlite3 (1.3.3) sqlite3-ruby (1.3.3, 1.2.5) stemmer (1.0.1) syntax (1.0.0) technicalpickles-jeweler (1.2.1) term-ansicolor (1.0.5, 1.0.4) Text (1.1.2) thinking-sphinx (1.3.18, 1.3.14) thor (0.14.6) thoughtbot-factory_girl (1.2.2) thrift (0.2.0.4) thrift_client (0.3.3, 0.3.1) tilt (1.2.2) timetrap (1.7.4, 1.4.0, 1.3.0, 1.2.1, 1.2.0, 1.1.3, 1.1.2) treetop (1.4.9, 1.4.8, 1.4.2) tzinfo (0.3.26, 0.3.25, 0.3.24) uuid (2.1.0, 2.0.1) uuidtools (2.1.2, 2.1.1) vegas (0.1.8) vlad (1.3.2) webrat (0.7.0, 0.6.0, 0.4.4) will_paginate (2.3.11) xhtmldiff (1.0.0) xml-simple (1.0.14, 1.0.12) xmpp4r (0.4) ya2yaml (0.26) ZenTest (4.1.4) ---------------------------------------------------------------------- Comment By: Sam Goldstein (samgoldstein) Date: 2011-04-05 15:02 Message: BTW the first environment load was with gem version 1.3.5 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29116&group_id=126 From noreply at rubyforge.org Wed Jun 1 12:06:08 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 1 Jun 2011 12:06:08 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29232 ] undefined method `specifications' for "...path":String Message-ID: <20110601160608.D0F041858361@rubyforge.org> Bugs item #29232, was opened at 2011-05-26 19:06 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29232&group_id=126 Category: other Group: None Status: Open Resolution: Rejected Priority: 3 Submitted By: Dave Myron (orangechicken) Assigned to: Ryan Davis (zenspider) Summary: undefined method `specifications' for "...path":String Initial Comment: With: RVM 1.6.16 Rubygems: 1.8.4 (& 1.8.3) Ruby: 1.9.2p180 (2011-02-18 revision 30909) [x86_64-darwin10.6.0] Running `rake -T --trace` results in the following stack trace: rake aborted! undefined method `specifications' for "/Users/dave/.rvm/gems/ruby-1.9.2-p180 at device_profiler":String /Users/dave/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems.rb:425:in `block in each_load_path' /Users/dave/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems.rb:423:in `each' /Users/dave/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems.rb:423:in `each_load_path' /Users/dave/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems.rb:587:in `block in latest_load_paths' /Users/dave/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems.rb:586:in `each' /Users/dave/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems.rb:586:in `latest_load_paths' /Users/dave/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/deprecate.rb:62:in `block (2 levels) in deprecate' /Users/dave/.rvm/gems/ruby-1.9.2-p180 at device_profiler/gems/spork-0.8.5/lib/spork.rb:112:in `other_spork_gem_load_paths' /Users/dave/.rvm/gems/ruby-1.9.2-p180 at device_profiler/gems/spork-0.8.5/lib/spork.rb:105:in `detect_and_require' /Users/dave/.rvm/gems/ruby-1.9.2-p180 at device_profiler/gems/spork-0.8.5/lib/spork/test_framework.rb:167:in `' /Users/dave/.rvm/gems/ruby-1.9.2-p180 at device_profiler/gems/rspec-core-2.6.3/lib/rspec/monkey/spork/test_framework/rspec.rb:2:in `' /Users/dave/.rvm/gems/ruby-1.9.2-p180 at device_profiler/gems/activesupport-3.0.7/lib/active_support/dependencies.rb:239:in `require' /Users/dave/.rvm/gems/ruby-1.9.2-p180 at device_profiler/gems/activesupport-3.0.7/lib/active_support/dependencies.rb:239:in `block in require' /Users/dave/.rvm/gems/ruby-1.9.2-p180 at device_profiler/gems/activesupport-3.0.7/lib/active_support/dependencies.rb:225:in `block in load_dependency' /Users/dave/.rvm/gems/ruby-1.9.2-p180 at device_profiler/gems/activesupport-3.0.7/lib/active_support/dependencies.rb:596:in `new_constants_in' /Users/dave/.rvm/gems/ruby-1.9.2-p180 at device_profiler/gems/activesupport-3.0.7/lib/active_support/dependencies.rb:225:in `load_dependency' /Users/dave/.rvm/gems/ruby-1.9.2-p180 at device_profiler/gems/activesupport-3.0.7/lib/active_support/dependencies.rb:239:in `require' /Users/dave/.rvm/gems/ruby-1.9.2-p180 at device_profiler/gems/rspec-core-2.6.3/lib/rspec/monkey.rb:1:in `' /Users/dave/.rvm/gems/ruby-1.9.2-p180 at device_profiler/gems/activesupport-3.0.7/lib/active_support/dependencies.rb:239:in `require' /Users/dave/.rvm/gems/ruby-1.9.2-p180 at device_profiler/gems/activesupport-3.0.7/lib/active_support/dependencies.rb:239:in `block in require' /Users/dave/.rvm/gems/ruby-1.9.2-p180 at device_profiler/gems/activesupport-3.0.7/lib/active_support/dependencies.rb:225:in `block in load_dependency' /Users/dave/.rvm/gems/ruby-1.9.2-p180 at device_profiler/gems/activesupport-3.0.7/lib/active_support/dependencies.rb:596:in `new_constants_in' /Users/dave/.rvm/gems/ruby-1.9.2-p180 at device_profiler/gems/activesupport-3.0.7/lib/active_support/dependencies.rb:225:in `load_dependency' /Users/dave/.rvm/gems/ruby-1.9.2-p180 at device_profiler/gems/activesupport-3.0.7/lib/active_support/dependencies.rb:239:in `require' /Users/dave/.rvm/gems/ruby-1.9.2-p180 at device_profiler/gems/rspec-core-2.6.3/lib/rspec/core.rb:103:in `' /Users/dave/.rvm/gems/ruby-1.9.2-p180 at device_profiler/gems/activesupport-3.0.7/lib/active_support/dependencies.rb:239:in `require' /Users/dave/.rvm/gems/ruby-1.9.2-p180 at device_profiler/gems/activesupport-3.0.7/lib/active_support/dependencies.rb:239:in `block in require' /Users/dave/.rvm/gems/ruby-1.9.2-p180 at device_profiler/gems/activesupport-3.0.7/lib/active_support/dependencies.rb:225:in `block in load_dependency' /Users/dave/.rvm/gems/ruby-1.9.2-p180 at device_profiler/gems/activesupport-3.0.7/lib/active_support/dependencies.rb:596:in `new_constants_in' /Users/dave/.rvm/gems/ruby-1.9.2-p180 at device_profiler/gems/activesupport-3.0.7/lib/active_support/dependencies.rb:225:in `load_dependency' /Users/dave/.rvm/gems/ruby-1.9.2-p180 at device_profiler/gems/activesupport-3.0.7/lib/active_support/dependencies.rb:239:in `require' /Users/dave/.rvm/gems/ruby-1.9.2-p180 at device_profiler/bundler/gems/rspec-rails-d3894ad27387/lib/rspec/rails/tasks/rspec.rake:1:in `' /Users/dave/.rvm/gems/ruby-1.9.2-p180 at device_profiler/gems/activesupport-3.0.7/lib/active_support/dependencies.rb:235:in `load' /Users/dave/.rvm/gems/ruby-1.9.2-p180 at device_profiler/gems/activesupport-3.0.7/lib/active_support/dependencies.rb:235:in `block in load' /Users/dave/.rvm/gems/ruby-1.9.2-p180 at device_profiler/gems/activesupport-3.0.7/lib/active_support/dependencies.rb:225:in `block in load_dependency' /Users/dave/.rvm/gems/ruby-1.9.2-p180 at device_profiler/gems/activesupport-3.0.7/lib/active_support/dependencies.rb:596:in `new_constants_in' /Users/dave/.rvm/gems/ruby-1.9.2-p180 at device_profiler/gems/activesupport-3.0.7/lib/active_support/dependencies.rb:225:in `load_dependency' /Users/dave/.rvm/gems/ruby-1.9.2-p180 at device_profiler/gems/activesupport-3.0.7/lib/active_support/dependencies.rb:235:in `load' /Users/dave/.rvm/gems/ruby-1.9.2-p180 at device_profiler/bundler/gems/rspec-rails-d3894ad27387/lib/rspec-rails.rb:10:in `block in ' /Users/dave/.rvm/gems/ruby-1.9.2-p180 at device_profiler/gems/railties-3.0.7/lib/rails/railtie.rb:184:in `call' /Users/dave/.rvm/gems/ruby-1.9.2-p180 at device_profiler/gems/railties-3.0.7/lib/rails/railtie.rb:184:in `each' /Users/dave/.rvm/gems/ruby-1.9.2-p180 at device_profiler/gems/railties-3.0.7/lib/rails/railtie.rb:184:in `load_tasks' /Users/dave/.rvm/gems/ruby-1.9.2-p180 at device_profiler/gems/railties-3.0.7/lib/rails/application.rb:140:in `block in load_tasks' /Users/dave/.rvm/gems/ruby-1.9.2-p180 at device_profiler/gems/railties-3.0.7/lib/rails/application/railties.rb:11:in `each' /Users/dave/.rvm/gems/ruby-1.9.2-p180 at device_profiler/gems/railties-3.0.7/lib/rails/application/railties.rb:11:in `all' /Users/dave/.rvm/gems/ruby-1.9.2-p180 at device_profiler/gems/railties-3.0.7/lib/rails/application.rb:140:in `load_tasks' /Users/dave/.rvm/gems/ruby-1.9.2-p180 at device_profiler/gems/railties-3.0.7/lib/rails/application.rb:77:in `method_missing' /Users/dave/Sites/fiddleback-related/device_profiler/Rakefile:7:in `' /Users/dave/.rvm/gems/ruby-1.9.2-p180 at device_profiler/gems/rake-0.8.7/lib/rake.rb:2383:in `load' /Users/dave/.rvm/gems/ruby-1.9.2-p180 at device_profiler/gems/rake-0.8.7/lib/rake.rb:2383:in `raw_load_rakefile' /Users/dave/.rvm/gems/ruby-1.9.2-p180 at device_profiler/gems/rake-0.8.7/lib/rake.rb:2017:in `block in load_rakefile' /Users/dave/.rvm/gems/ruby-1.9.2-p180 at device_profiler/gems/rake-0.8.7/lib/rake.rb:2068:in `standard_exception_handling' /Users/dave/.rvm/gems/ruby-1.9.2-p180 at device_profiler/gems/rake-0.8.7/lib/rake.rb:2016:in `load_rakefile' /Users/dave/.rvm/gems/ruby-1.9.2-p180 at device_profiler/gems/rake-0.8.7/lib/rake.rb:2000:in `block in run' /Users/dave/.rvm/gems/ruby-1.9.2-p180 at device_profiler/gems/rake-0.8.7/lib/rake.rb:2068:in `standard_exception_handling' /Users/dave/.rvm/gems/ruby-1.9.2-p180 at device_profiler/gems/rake-0.8.7/lib/rake.rb:1998:in `run' /Users/dave/.rvm/gems/ruby-1.9.2-p180 at device_profiler/gems/rake-0.8.7/bin/rake:31:in `' /Users/dave/.rvm/gems/ruby-1.9.2-p180 at device_profiler/bin/rake:19:in `load' /Users/dave/.rvm/gems/ruby-1.9.2-p180 at device_profiler/bin/rake:19:in `
' Line 425 in rubygems.rb attempts to use a string as some type of object that is supposed to have a #specifications method. Running `rvm rubygems current` rolls back to 1.6.2 and the problem disappears. ---------------------------------------------------------------------- Comment By: Andrew Nordman (cadwallion) Date: 2011-06-01 11:06 Message: It looks like it's an issue caused by having rspec-rails and spork together. Steps taken to reproduce: 1. rails new foo 2. edit gemfile to the following: source 'http://rubygems.org' gem 'rails', '3.0.8.rc4' gem 'sqlite3' group :test, :development do gem 'rspec-rails', '2.6.0' gem 'spork', '0.8.5' end 3. bundle install 4. rake -T This will generate the error. When tested against the spork repo master ( gem 'spork', :git => "https://github.com/timcharper/spork.git") it does not error. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-05-31 18:37 Message: No repro... c'mon guys... ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-05-28 18:58 Message: Can you provide some means of repro? And can you also test against spork trunk? ---------------------------------------------------------------------- Comment By: Michael Bleigh (mbleigh) Date: 2011-05-27 18:30 Message: I'm experiencing the same problem and had similar luck fixing it by rolling back RubyGems. It was happening to me when trying to run a rake task in a Rails 3 app. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29232&group_id=126 From noreply at rubyforge.org Wed Jun 1 12:16:37 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 1 Jun 2011 12:16:37 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29163 ] Invalid specs resulting from incorrect syck time parsing Message-ID: <20110601161637.62B301858361@rubyforge.org> Bugs item #29163, was opened at 2011-05-04 23:14 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29163&group_id=126 Category: `gem` commands (other) Group: next Status: Open Resolution: None Priority: 3 Submitted By: Bruno Michel (nono) Assigned to: Ryan Davis (zenspider) Summary: Invalid specs resulting from incorrect syck time parsing Initial Comment: Hi, I have the bug described on https://github.com/rubygems/rubygems/pull/57 with Ruby 1.9.2-p180 and Rubygems v1.8.0. If I generate a gem with `gem build`, the `date` field in the metadata of the generated gem is: date: 2011-05-04 00:00:00.000000000Z If I push this gem on rubygems.org and try to install it remotely (same PC), this does not works: ERROR: While executing gem ... (NameError) uninitialized constant Psych::Syck ---------------------------------------------------------------------- >Comment By: Evan Phoenix (evan) Date: 2011-06-01 16:16 Message: This is because html_spellchecker has an instance of YAML::Syck::DefaultKey in its gemspec. These should not be in gemspecs and the gem needs to be regenerated. I'm looking into a way to mitigate this in the mean time. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-05-24 10:20 Message: I think it is your cache... That URL looks OK via: curl http://gems:Nasom4 at gems.af83.com/specs.4.8.gz | gunzip -dc | ruby -Ilib -rubygems -e 'p Marshal.load $stdin.read' ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-05-24 10:12 Message: Bruno, this installs fine for me as you can see below... From your output, I suspect you might have a bad source in your list. Specifically "gems.af83.com" looks like it might be bad for you. Can you do `gem sources -c` to ensure that your sources are default and your caches are cleared and try again to verify? % gem i -i xxx html_spellchecker --version=0.1.1 -V --backtrace GET http://rubygems.org/specs.4.8.gz 302 Found GET http://production.s3.rubygems.org/specs.4.8.gz 200 OK GET http://rubygems.org/quick/Marshal.4.8/html_spellchecker-0.1.1.gemspec.rz ... and so on to completion ... ---------------------------------------------------------------------- Comment By: Bruno Michel (nono) Date: 2011-05-24 09:43 Message: Hi, for example: ~% gem install html_spellchecker --version=0.1.1 -V --backtrace GET http://rubygems.org/specs.4.8.gz 302 Found GET http://production.s3.rubygems.org/specs.4.8.gz 304 Not Modified GET http://gems:Nasom4 at gems.af83.com/specs.4.8.gz 200 OK ERROR: While executing gem ... (NameError) uninitialized constant Psych::Syck /home/nono/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:640:in `load' /home/nono/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:640:in `_load' /home/nono/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/spec_fetcher.rb:134:in `load' /home/nono/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/spec_fetcher.rb:134:in `fetch_spec' /home/nono/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/spec_fetcher.rb:95:in `block in fetch_with_errors' /home/nono/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/spec_fetcher.rb:94:in `map' /home/nono/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/spec_fetcher.rb:94:in `fetch_with_errors' /home/nono/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/dependency_installer.rb:110:in `find_gems_with_sources' /home/nono/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/dependency_installer.rb:228:in `find_spec_by_name_and_version' /home/nono/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/dependency_installer.rb:259:in `install' /home/nono/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/commands/install_command.rb:121:in `block in execute' /home/nono/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/commands/install_command.rb:115:in `each' /home/nono/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/commands/install_command.rb:115:in `execute' /home/nono/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/command.rb:278:in `invoke' /home/nono/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/command_manager.rb:147:in `process_args' /home/nono/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/command_manager.rb:117:in `run' /home/nono/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/gem_runner.rb:65:in `run' /home/nono/.rvm/rubies/ruby-1.9.2-p180/bin/gem:21:in `
' zsh: exit 1 ~% gem -v 1.8.3 ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-05-24 00:38 Message: I need a full backtrace and the gem name+version to properly investigate. Your error doesn't jive with the date problem. (If I'm remembering the error correctly). ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29163&group_id=126 From noreply at rubyforge.org Wed Jun 1 14:09:39 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 1 Jun 2011 14:09:39 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29163 ] Invalid specs resulting from incorrect syck time parsing Message-ID: <20110601180939.2C3B01858363@rubyforge.org> Bugs item #29163, was opened at 2011-05-04 23:14 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29163&group_id=126 Category: `gem` commands (other) Group: next >Status: Closed Resolution: None Priority: 3 Submitted By: Bruno Michel (nono) >Assigned to: Evan Phoenix (evan) Summary: Invalid specs resulting from incorrect syck time parsing Initial Comment: Hi, I have the bug described on https://github.com/rubygems/rubygems/pull/57 with Ruby 1.9.2-p180 and Rubygems v1.8.0. If I generate a gem with `gem build`, the `date` field in the metadata of the generated gem is: date: 2011-05-04 00:00:00.000000000Z If I push this gem on rubygems.org and try to install it remotely (same PC), this does not works: ERROR: While executing gem ... (NameError) uninitialized constant Psych::Syck ---------------------------------------------------------------------- >Comment By: Evan Phoenix (evan) Date: 2011-06-01 18:09 Message: I've fixed this by having the DefaultKey class always available and having Requirement fix up any reference to it. Fixed in github:0f4067a ---------------------------------------------------------------------- Comment By: Evan Phoenix (evan) Date: 2011-06-01 16:16 Message: This is because html_spellchecker has an instance of YAML::Syck::DefaultKey in its gemspec. These should not be in gemspecs and the gem needs to be regenerated. I'm looking into a way to mitigate this in the mean time. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-05-24 10:20 Message: I think it is your cache... That URL looks OK via: curl http://gems:Nasom4 at gems.af83.com/specs.4.8.gz | gunzip -dc | ruby -Ilib -rubygems -e 'p Marshal.load $stdin.read' ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-05-24 10:12 Message: Bruno, this installs fine for me as you can see below... From your output, I suspect you might have a bad source in your list. Specifically "gems.af83.com" looks like it might be bad for you. Can you do `gem sources -c` to ensure that your sources are default and your caches are cleared and try again to verify? % gem i -i xxx html_spellchecker --version=0.1.1 -V --backtrace GET http://rubygems.org/specs.4.8.gz 302 Found GET http://production.s3.rubygems.org/specs.4.8.gz 200 OK GET http://rubygems.org/quick/Marshal.4.8/html_spellchecker-0.1.1.gemspec.rz ... and so on to completion ... ---------------------------------------------------------------------- Comment By: Bruno Michel (nono) Date: 2011-05-24 09:43 Message: Hi, for example: ~% gem install html_spellchecker --version=0.1.1 -V --backtrace GET http://rubygems.org/specs.4.8.gz 302 Found GET http://production.s3.rubygems.org/specs.4.8.gz 304 Not Modified GET http://gems:Nasom4 at gems.af83.com/specs.4.8.gz 200 OK ERROR: While executing gem ... (NameError) uninitialized constant Psych::Syck /home/nono/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:640:in `load' /home/nono/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:640:in `_load' /home/nono/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/spec_fetcher.rb:134:in `load' /home/nono/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/spec_fetcher.rb:134:in `fetch_spec' /home/nono/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/spec_fetcher.rb:95:in `block in fetch_with_errors' /home/nono/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/spec_fetcher.rb:94:in `map' /home/nono/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/spec_fetcher.rb:94:in `fetch_with_errors' /home/nono/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/dependency_installer.rb:110:in `find_gems_with_sources' /home/nono/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/dependency_installer.rb:228:in `find_spec_by_name_and_version' /home/nono/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/dependency_installer.rb:259:in `install' /home/nono/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/commands/install_command.rb:121:in `block in execute' /home/nono/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/commands/install_command.rb:115:in `each' /home/nono/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/commands/install_command.rb:115:in `execute' /home/nono/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/command.rb:278:in `invoke' /home/nono/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/command_manager.rb:147:in `process_args' /home/nono/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/command_manager.rb:117:in `run' /home/nono/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/gem_runner.rb:65:in `run' /home/nono/.rvm/rubies/ruby-1.9.2-p180/bin/gem:21:in `
' zsh: exit 1 ~% gem -v 1.8.3 ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-05-24 00:38 Message: I need a full backtrace and the gem name+version to properly investigate. Your error doesn't jive with the date problem. (If I'm remembering the error correctly). ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29163&group_id=126 From noreply at rubyforge.org Wed Jun 1 15:13:27 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 1 Jun 2011 15:13:27 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29163 ] Invalid specs resulting from incorrect syck time parsing Message-ID: <20110601191328.029561858363@rubyforge.org> Bugs item #29163, was opened at 05/05/2011 01:14 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29163&group_id=126 Category: `gem` commands (other) Group: next Status: Closed Resolution: None Priority: 3 Submitted By: Bruno Michel (nono) Assigned to: Evan Phoenix (evan) Summary: Invalid specs resulting from incorrect syck time parsing Initial Comment: Hi, I have the bug described on https://github.com/rubygems/rubygems/pull/57 with Ruby 1.9.2-p180 and Rubygems v1.8.0. If I generate a gem with `gem build`, the `date` field in the metadata of the generated gem is: date: 2011-05-04 00:00:00.000000000Z If I push this gem on rubygems.org and try to install it remotely (same PC), this does not works: ERROR: While executing gem ... (NameError) uninitialized constant Psych::Syck ---------------------------------------------------------------------- >Comment By: Bruno Michel (nono) Date: 01/06/2011 21:13 Message: Thanks for the explanation. The gem was regenerated with a Ruby 1.8 and a new version was pushed. If I want to build the next version with Ruby 1.9, how can I can be sure the new gem don't have a YAML::Syck::DefaultKey? ---------------------------------------------------------------------- Comment By: Evan Phoenix (evan) Date: 01/06/2011 20:09 Message: I've fixed this by having the DefaultKey class always available and having Requirement fix up any reference to it. Fixed in github:0f4067a ---------------------------------------------------------------------- Comment By: Evan Phoenix (evan) Date: 01/06/2011 18:16 Message: This is because html_spellchecker has an instance of YAML::Syck::DefaultKey in its gemspec. These should not be in gemspecs and the gem needs to be regenerated. I'm looking into a way to mitigate this in the mean time. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 24/05/2011 12:20 Message: I think it is your cache... That URL looks OK via: curl http://gems:Nasom4 at gems.af83.com/specs.4.8.gz | gunzip -dc | ruby -Ilib -rubygems -e 'p Marshal.load $stdin.read' ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 24/05/2011 12:12 Message: Bruno, this installs fine for me as you can see below... From your output, I suspect you might have a bad source in your list. Specifically "gems.af83.com" looks like it might be bad for you. Can you do `gem sources -c` to ensure that your sources are default and your caches are cleared and try again to verify? % gem i -i xxx html_spellchecker --version=0.1.1 -V --backtrace GET http://rubygems.org/specs.4.8.gz 302 Found GET http://production.s3.rubygems.org/specs.4.8.gz 200 OK GET http://rubygems.org/quick/Marshal.4.8/html_spellchecker-0.1.1.gemspec.rz ... and so on to completion ... ---------------------------------------------------------------------- Comment By: Bruno Michel (nono) Date: 24/05/2011 11:43 Message: Hi, for example: ~% gem install html_spellchecker --version=0.1.1 -V --backtrace GET http://rubygems.org/specs.4.8.gz 302 Found GET http://production.s3.rubygems.org/specs.4.8.gz 304 Not Modified GET http://gems:Nasom4 at gems.af83.com/specs.4.8.gz 200 OK ERROR: While executing gem ... (NameError) uninitialized constant Psych::Syck /home/nono/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:640:in `load' /home/nono/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:640:in `_load' /home/nono/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/spec_fetcher.rb:134:in `load' /home/nono/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/spec_fetcher.rb:134:in `fetch_spec' /home/nono/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/spec_fetcher.rb:95:in `block in fetch_with_errors' /home/nono/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/spec_fetcher.rb:94:in `map' /home/nono/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/spec_fetcher.rb:94:in `fetch_with_errors' /home/nono/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/dependency_installer.rb:110:in `find_gems_with_sources' /home/nono/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/dependency_installer.rb:228:in `find_spec_by_name_and_version' /home/nono/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/dependency_installer.rb:259:in `install' /home/nono/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/commands/install_command.rb:121:in `block in execute' /home/nono/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/commands/install_command.rb:115:in `each' /home/nono/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/commands/install_command.rb:115:in `execute' /home/nono/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/command.rb:278:in `invoke' /home/nono/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/command_manager.rb:147:in `process_args' /home/nono/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/command_manager.rb:117:in `run' /home/nono/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/gem_runner.rb:65:in `run' /home/nono/.rvm/rubies/ruby-1.9.2-p180/bin/gem:21:in `
' zsh: exit 1 ~% gem -v 1.8.3 ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 24/05/2011 02:38 Message: I need a full backtrace and the gem name+version to properly investigate. Your error doesn't jive with the date problem. (If I'm remembering the error correctly). ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29163&group_id=126 From noreply at rubyforge.org Wed Jun 1 16:42:51 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 1 Jun 2011 16:42:51 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29163 ] Invalid specs resulting from incorrect syck time parsing Message-ID: <20110601204251.7AF5D1858378@rubyforge.org> Bugs item #29163, was opened at 2011-05-04 16:14 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29163&group_id=126 Category: `gem` commands (other) Group: next Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Bruno Michel (nono) Assigned to: Evan Phoenix (evan) Summary: Invalid specs resulting from incorrect syck time parsing Initial Comment: Hi, I have the bug described on https://github.com/rubygems/rubygems/pull/57 with Ruby 1.9.2-p180 and Rubygems v1.8.0. If I generate a gem with `gem build`, the `date` field in the metadata of the generated gem is: date: 2011-05-04 00:00:00.000000000Z If I push this gem on rubygems.org and try to install it remotely (same PC), this does not works: ERROR: While executing gem ... (NameError) uninitialized constant Psych::Syck ---------------------------------------------------------------------- >Comment By: Ryan Davis (zenspider) Date: 2011-06-01 13:42 Message: The problem is that psych will generate a perfectly valid string that starts with an unquoted '='. Syck has a bug parsing that and winds up using DefaultKey. ---------------------------------------------------------------------- Comment By: Bruno Michel (nono) Date: 2011-06-01 12:13 Message: Thanks for the explanation. The gem was regenerated with a Ruby 1.8 and a new version was pushed. If I want to build the next version with Ruby 1.9, how can I can be sure the new gem don't have a YAML::Syck::DefaultKey? ---------------------------------------------------------------------- Comment By: Evan Phoenix (evan) Date: 2011-06-01 11:09 Message: I've fixed this by having the DefaultKey class always available and having Requirement fix up any reference to it. Fixed in github:0f4067a ---------------------------------------------------------------------- Comment By: Evan Phoenix (evan) Date: 2011-06-01 09:16 Message: This is because html_spellchecker has an instance of YAML::Syck::DefaultKey in its gemspec. These should not be in gemspecs and the gem needs to be regenerated. I'm looking into a way to mitigate this in the mean time. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-05-24 03:20 Message: I think it is your cache... That URL looks OK via: curl http://gems:Nasom4 at gems.af83.com/specs.4.8.gz | gunzip -dc | ruby -Ilib -rubygems -e 'p Marshal.load $stdin.read' ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-05-24 03:12 Message: Bruno, this installs fine for me as you can see below... From your output, I suspect you might have a bad source in your list. Specifically "gems.af83.com" looks like it might be bad for you. Can you do `gem sources -c` to ensure that your sources are default and your caches are cleared and try again to verify? % gem i -i xxx html_spellchecker --version=0.1.1 -V --backtrace GET http://rubygems.org/specs.4.8.gz 302 Found GET http://production.s3.rubygems.org/specs.4.8.gz 200 OK GET http://rubygems.org/quick/Marshal.4.8/html_spellchecker-0.1.1.gemspec.rz ... and so on to completion ... ---------------------------------------------------------------------- Comment By: Bruno Michel (nono) Date: 2011-05-24 02:43 Message: Hi, for example: ~% gem install html_spellchecker --version=0.1.1 -V --backtrace GET http://rubygems.org/specs.4.8.gz 302 Found GET http://production.s3.rubygems.org/specs.4.8.gz 304 Not Modified GET http://gems:Nasom4 at gems.af83.com/specs.4.8.gz 200 OK ERROR: While executing gem ... (NameError) uninitialized constant Psych::Syck /home/nono/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:640:in `load' /home/nono/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:640:in `_load' /home/nono/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/spec_fetcher.rb:134:in `load' /home/nono/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/spec_fetcher.rb:134:in `fetch_spec' /home/nono/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/spec_fetcher.rb:95:in `block in fetch_with_errors' /home/nono/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/spec_fetcher.rb:94:in `map' /home/nono/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/spec_fetcher.rb:94:in `fetch_with_errors' /home/nono/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/dependency_installer.rb:110:in `find_gems_with_sources' /home/nono/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/dependency_installer.rb:228:in `find_spec_by_name_and_version' /home/nono/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/dependency_installer.rb:259:in `install' /home/nono/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/commands/install_command.rb:121:in `block in execute' /home/nono/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/commands/install_command.rb:115:in `each' /home/nono/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/commands/install_command.rb:115:in `execute' /home/nono/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/command.rb:278:in `invoke' /home/nono/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/command_manager.rb:147:in `process_args' /home/nono/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/command_manager.rb:117:in `run' /home/nono/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/gem_runner.rb:65:in `run' /home/nono/.rvm/rubies/ruby-1.9.2-p180/bin/gem:21:in `
' zsh: exit 1 ~% gem -v 1.8.3 ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-05-23 17:38 Message: I need a full backtrace and the gem name+version to properly investigate. Your error doesn't jive with the date problem. (If I'm remembering the error correctly). ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29163&group_id=126 From noreply at rubyforge.org Wed Jun 1 16:45:59 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 1 Jun 2011 16:45:59 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29163 ] Invalid specs resulting from incorrect syck time parsing Message-ID: <20110601204559.3D7851858377@rubyforge.org> Bugs item #29163, was opened at 2011-05-04 23:14 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29163&group_id=126 Category: `gem` commands (other) Group: next Status: Closed Resolution: Accepted Priority: 3 Submitted By: Bruno Michel (nono) Assigned to: Evan Phoenix (evan) Summary: Invalid specs resulting from incorrect syck time parsing Initial Comment: Hi, I have the bug described on https://github.com/rubygems/rubygems/pull/57 with Ruby 1.9.2-p180 and Rubygems v1.8.0. If I generate a gem with `gem build`, the `date` field in the metadata of the generated gem is: date: 2011-05-04 00:00:00.000000000Z If I push this gem on rubygems.org and try to install it remotely (same PC), this does not works: ERROR: While executing gem ... (NameError) uninitialized constant Psych::Syck ---------------------------------------------------------------------- >Comment By: Evan Phoenix (evan) Date: 2011-06-01 20:45 Message: Yep. You can see the syck bug by running this code: YAML.load "- - =\n - 1\n" You'll see that syck puts DefaultKey in there, which is just plain wrong. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-06-01 20:42 Message: The problem is that psych will generate a perfectly valid string that starts with an unquoted '='. Syck has a bug parsing that and winds up using DefaultKey. ---------------------------------------------------------------------- Comment By: Bruno Michel (nono) Date: 2011-06-01 19:13 Message: Thanks for the explanation. The gem was regenerated with a Ruby 1.8 and a new version was pushed. If I want to build the next version with Ruby 1.9, how can I can be sure the new gem don't have a YAML::Syck::DefaultKey? ---------------------------------------------------------------------- Comment By: Evan Phoenix (evan) Date: 2011-06-01 18:09 Message: I've fixed this by having the DefaultKey class always available and having Requirement fix up any reference to it. Fixed in github:0f4067a ---------------------------------------------------------------------- Comment By: Evan Phoenix (evan) Date: 2011-06-01 16:16 Message: This is because html_spellchecker has an instance of YAML::Syck::DefaultKey in its gemspec. These should not be in gemspecs and the gem needs to be regenerated. I'm looking into a way to mitigate this in the mean time. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-05-24 10:20 Message: I think it is your cache... That URL looks OK via: curl http://gems:Nasom4 at gems.af83.com/specs.4.8.gz | gunzip -dc | ruby -Ilib -rubygems -e 'p Marshal.load $stdin.read' ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-05-24 10:12 Message: Bruno, this installs fine for me as you can see below... From your output, I suspect you might have a bad source in your list. Specifically "gems.af83.com" looks like it might be bad for you. Can you do `gem sources -c` to ensure that your sources are default and your caches are cleared and try again to verify? % gem i -i xxx html_spellchecker --version=0.1.1 -V --backtrace GET http://rubygems.org/specs.4.8.gz 302 Found GET http://production.s3.rubygems.org/specs.4.8.gz 200 OK GET http://rubygems.org/quick/Marshal.4.8/html_spellchecker-0.1.1.gemspec.rz ... and so on to completion ... ---------------------------------------------------------------------- Comment By: Bruno Michel (nono) Date: 2011-05-24 09:43 Message: Hi, for example: ~% gem install html_spellchecker --version=0.1.1 -V --backtrace GET http://rubygems.org/specs.4.8.gz 302 Found GET http://production.s3.rubygems.org/specs.4.8.gz 304 Not Modified GET http://gems:Nasom4 at gems.af83.com/specs.4.8.gz 200 OK ERROR: While executing gem ... (NameError) uninitialized constant Psych::Syck /home/nono/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:640:in `load' /home/nono/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:640:in `_load' /home/nono/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/spec_fetcher.rb:134:in `load' /home/nono/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/spec_fetcher.rb:134:in `fetch_spec' /home/nono/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/spec_fetcher.rb:95:in `block in fetch_with_errors' /home/nono/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/spec_fetcher.rb:94:in `map' /home/nono/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/spec_fetcher.rb:94:in `fetch_with_errors' /home/nono/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/dependency_installer.rb:110:in `find_gems_with_sources' /home/nono/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/dependency_installer.rb:228:in `find_spec_by_name_and_version' /home/nono/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/dependency_installer.rb:259:in `install' /home/nono/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/commands/install_command.rb:121:in `block in execute' /home/nono/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/commands/install_command.rb:115:in `each' /home/nono/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/commands/install_command.rb:115:in `execute' /home/nono/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/command.rb:278:in `invoke' /home/nono/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/command_manager.rb:147:in `process_args' /home/nono/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/command_manager.rb:117:in `run' /home/nono/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/gem_runner.rb:65:in `run' /home/nono/.rvm/rubies/ruby-1.9.2-p180/bin/gem:21:in `
' zsh: exit 1 ~% gem -v 1.8.3 ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-05-24 00:38 Message: I need a full backtrace and the gem name+version to properly investigate. Your error doesn't jive with the date problem. (If I'm remembering the error correctly). ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29163&group_id=126 From noreply at rubyforge.org Wed Jun 1 16:53:06 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 1 Jun 2011 16:53:06 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29163 ] Invalid specs resulting from incorrect syck time parsing Message-ID: <20110601205306.E85CE1858378@rubyforge.org> Bugs item #29163, was opened at 05/05/2011 01:14 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29163&group_id=126 Category: `gem` commands (other) Group: next Status: Closed Resolution: Accepted Priority: 3 Submitted By: Bruno Michel (nono) Assigned to: Evan Phoenix (evan) Summary: Invalid specs resulting from incorrect syck time parsing Initial Comment: Hi, I have the bug described on https://github.com/rubygems/rubygems/pull/57 with Ruby 1.9.2-p180 and Rubygems v1.8.0. If I generate a gem with `gem build`, the `date` field in the metadata of the generated gem is: date: 2011-05-04 00:00:00.000000000Z If I push this gem on rubygems.org and try to install it remotely (same PC), this does not works: ERROR: While executing gem ... (NameError) uninitialized constant Psych::Syck ---------------------------------------------------------------------- >Comment By: Bruno Michel (nono) Date: 01/06/2011 22:53 Message: Oki, now I understand from where this DefaultKey come. Thanks ---------------------------------------------------------------------- Comment By: Evan Phoenix (evan) Date: 01/06/2011 22:45 Message: Yep. You can see the syck bug by running this code: YAML.load "- - =\n - 1\n" You'll see that syck puts DefaultKey in there, which is just plain wrong. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 01/06/2011 22:42 Message: The problem is that psych will generate a perfectly valid string that starts with an unquoted '='. Syck has a bug parsing that and winds up using DefaultKey. ---------------------------------------------------------------------- Comment By: Bruno Michel (nono) Date: 01/06/2011 21:13 Message: Thanks for the explanation. The gem was regenerated with a Ruby 1.8 and a new version was pushed. If I want to build the next version with Ruby 1.9, how can I can be sure the new gem don't have a YAML::Syck::DefaultKey? ---------------------------------------------------------------------- Comment By: Evan Phoenix (evan) Date: 01/06/2011 20:09 Message: I've fixed this by having the DefaultKey class always available and having Requirement fix up any reference to it. Fixed in github:0f4067a ---------------------------------------------------------------------- Comment By: Evan Phoenix (evan) Date: 01/06/2011 18:16 Message: This is because html_spellchecker has an instance of YAML::Syck::DefaultKey in its gemspec. These should not be in gemspecs and the gem needs to be regenerated. I'm looking into a way to mitigate this in the mean time. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 24/05/2011 12:20 Message: I think it is your cache... That URL looks OK via: curl http://gems:Nasom4 at gems.af83.com/specs.4.8.gz | gunzip -dc | ruby -Ilib -rubygems -e 'p Marshal.load $stdin.read' ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 24/05/2011 12:12 Message: Bruno, this installs fine for me as you can see below... From your output, I suspect you might have a bad source in your list. Specifically "gems.af83.com" looks like it might be bad for you. Can you do `gem sources -c` to ensure that your sources are default and your caches are cleared and try again to verify? % gem i -i xxx html_spellchecker --version=0.1.1 -V --backtrace GET http://rubygems.org/specs.4.8.gz 302 Found GET http://production.s3.rubygems.org/specs.4.8.gz 200 OK GET http://rubygems.org/quick/Marshal.4.8/html_spellchecker-0.1.1.gemspec.rz ... and so on to completion ... ---------------------------------------------------------------------- Comment By: Bruno Michel (nono) Date: 24/05/2011 11:43 Message: Hi, for example: ~% gem install html_spellchecker --version=0.1.1 -V --backtrace GET http://rubygems.org/specs.4.8.gz 302 Found GET http://production.s3.rubygems.org/specs.4.8.gz 304 Not Modified GET http://gems:Nasom4 at gems.af83.com/specs.4.8.gz 200 OK ERROR: While executing gem ... (NameError) uninitialized constant Psych::Syck /home/nono/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:640:in `load' /home/nono/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:640:in `_load' /home/nono/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/spec_fetcher.rb:134:in `load' /home/nono/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/spec_fetcher.rb:134:in `fetch_spec' /home/nono/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/spec_fetcher.rb:95:in `block in fetch_with_errors' /home/nono/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/spec_fetcher.rb:94:in `map' /home/nono/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/spec_fetcher.rb:94:in `fetch_with_errors' /home/nono/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/dependency_installer.rb:110:in `find_gems_with_sources' /home/nono/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/dependency_installer.rb:228:in `find_spec_by_name_and_version' /home/nono/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/dependency_installer.rb:259:in `install' /home/nono/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/commands/install_command.rb:121:in `block in execute' /home/nono/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/commands/install_command.rb:115:in `each' /home/nono/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/commands/install_command.rb:115:in `execute' /home/nono/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/command.rb:278:in `invoke' /home/nono/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/command_manager.rb:147:in `process_args' /home/nono/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/command_manager.rb:117:in `run' /home/nono/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/gem_runner.rb:65:in `run' /home/nono/.rvm/rubies/ruby-1.9.2-p180/bin/gem:21:in `
' zsh: exit 1 ~% gem -v 1.8.3 ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 24/05/2011 02:38 Message: I need a full backtrace and the gem name+version to properly investigate. Your error doesn't jive with the date problem. (If I'm remembering the error correctly). ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29163&group_id=126 From noreply at rubyforge.org Wed Jun 1 16:57:55 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 1 Jun 2011 16:57:55 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29166 ] gem installs dependencies for gems it never installed Message-ID: <20110601205756.E34F51678326@rubyforge.org> Bugs item #29166, was opened at 2011-05-05 07:34 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29166&group_id=126 Category: `gem install` command Group: None >Status: Closed Resolution: Accepted Priority: 3 Submitted By: Greg Hazel (ghazel) >Assigned to: Evan Phoenix (evan) Summary: gem installs dependencies for gems it never installed Initial Comment: C:\>gem install actionpack -v 2.3.11 Successfully installed actionpack-2.3.11 1 gem installed C:\>gem list actionpack *** LOCAL GEMS *** actionpack (2.3.11) C:\>gem dep -r subdomain_routes Gem subdomain_routes-0.3.1 actionpack (>= 2.2.1, runtime) C:\>gem install subdomain_routes Fetching: subdomain_routes-0.3.1.gem (100%) Fetching: activesupport-3.0.7.gem (100%) Fetching: activemodel-3.0.7.gem (100%) Successfully installed subdomain_routes-0.3.1 Successfully installed activesupport-3.0.7 Successfully installed activemodel-3.0.7 3 gems installed Why did it install activesupport-3.0.7 and activemodel-3.0.7? ---------------------------------------------------------------------- >Comment By: Evan Phoenix (evan) Date: 2011-06-01 20:57 Message: I've added --minimal-deps to install which will not attempt to upgrade any deps that a gem has (the reason that it installed other things in the first place). We may make this the default also. Fixed in github:af3405fd ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-05-06 00:01 Message: I'm de-escalating this ticket as it is not introduced by the activation change in 1.8 (which also we changed back). ---------------------------------------------------------------------- Comment By: Greg Hazel (ghazel) Date: 2011-05-05 22:10 Message: I tried to show that at the beginning. I have actionpack- 2.3.11 and everything it depends on, because I use Rails 2.3.11. When I installed subdomain_routes it did not install actionpack-3.0.7, but it did install some dependencies for actionpack-3.0.7 - very strange. My expectation would be that it would make sure the dependencies are satisfied - in my case actionpack-2.3.11 should satisfy it - and stop there. ---------------------------------------------------------------------- Comment By: Eric Hodel (drbrain) Date: 2011-05-05 18:56 Message: What is your gem list? Do you already have actionpack installed? If you already have some matching dependencies in the dependency tree RubyGems will install the missing dependencies. Ryan: This is from gem 1.4.2, not 1.8.0, so I think my change is fine, at least for this case. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-05-05 17:18 Message: Eric, I woke up realizing that this is because of you moving the activate. This will effect a lot more than installation and will require a point release today. ---------------------------------------------------------------------- Comment By: Greg Hazel (ghazel) Date: 2011-05-05 12:28 Message: C:\>gem --version 1.4.2 It depends on actionpack (>= 2.2.1). It did *not* install actionpack-3.0.7 ---------------------------------------------------------------------- Comment By: Luis Lavena (luislavena) Date: 2011-05-05 12:22 Message: Please provide the version of RubyGems you used. If a gem depends on >= it will always install the latest gem available. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29166&group_id=126 From noreply at rubyforge.org Wed Jun 1 23:50:20 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 1 Jun 2011 23:50:20 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29216 ] Bogus " WARNING You don't have X in your PATH" with --user-install --bindir options set Message-ID: <20110602035022.57377185838E@rubyforge.org> Bugs item #29216, was opened at 2011-05-19 21:42 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29216&group_id=126 Category: `gem install` command Group: None >Status: Closed Resolution: Accepted Priority: 3 Submitted By: David Kellum (dekellum) >Assigned to: Evan Phoenix (evan) Summary: Bogus "WARNING You don't have X in your PATH" with --user-install --bindir options set Initial Comment: On a gem install like the following: % gem install foo --user-install --bindir /home/david/bin WARNING: You don't have /home/david/.gem/jruby/1.8/bin in your PATH, gem executables will not run. Successfully installed foo-0.0.1 1 gem installed But the "--bindir /home/david/bin" should make "/home/david/.gem/jruby/1.8/bin" irrelevant. The bin wrappers for "foo" are indeed correctly installed to /home/david/bin. I'll have a simple patch for this... ---------------------------------------------------------------------- >Comment By: Evan Phoenix (evan) Date: 2011-06-02 03:50 Message: Fixed in github:7d740f1 ---------------------------------------------------------------------- Comment By: David Kellum (dekellum) Date: 2011-06-01 03:40 Message: Pull request is here: https://github.com/rubygems/rubygems/pull/62 Thanks. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-05-31 23:36 Message: Patch? (don't forget to check that stupid checkbox) OR just send me a pull request on github. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29216&group_id=126 From noreply at rubyforge.org Thu Jun 2 00:18:54 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 2 Jun 2011 00:18:54 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29232 ] undefined method `specifications' for "...path":String Message-ID: <20110602041854.E97E8185838E@rubyforge.org> Bugs item #29232, was opened at 2011-05-27 00:06 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29232&group_id=126 Category: other Group: None >Status: Closed Resolution: Rejected Priority: 3 Submitted By: Dave Myron (orangechicken) >Assigned to: Evan Phoenix (evan) >Summary: undefined method `specifications' for "...path":String Initial Comment: With: RVM 1.6.16 Rubygems: 1.8.4 (& 1.8.3) Ruby: 1.9.2p180 (2011-02-18 revision 30909) [x86_64-darwin10.6.0] Running `rake -T --trace` results in the following stack trace: rake aborted! undefined method `specifications' for "/Users/dave/.rvm/gems/ruby-1.9.2-p180 at device_profiler":String /Users/dave/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems.rb:425:in `block in each_load_path' /Users/dave/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems.rb:423:in `each' /Users/dave/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems.rb:423:in `each_load_path' /Users/dave/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems.rb:587:in `block in latest_load_paths' /Users/dave/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems.rb:586:in `each' /Users/dave/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems.rb:586:in `latest_load_paths' /Users/dave/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/deprecate.rb:62:in `block (2 levels) in deprecate' /Users/dave/.rvm/gems/ruby-1.9.2-p180 at device_profiler/gems/spork-0.8.5/lib/spork.rb:112:in `other_spork_gem_load_paths' /Users/dave/.rvm/gems/ruby-1.9.2-p180 at device_profiler/gems/spork-0.8.5/lib/spork.rb:105:in `detect_and_require' /Users/dave/.rvm/gems/ruby-1.9.2-p180 at device_profiler/gems/spork-0.8.5/lib/spork/test_framework.rb:167:in `' /Users/dave/.rvm/gems/ruby-1.9.2-p180 at device_profiler/gems/rspec-core-2.6.3/lib/rspec/monkey/spork/test_framework/rspec.rb:2:in `' /Users/dave/.rvm/gems/ruby-1.9.2-p180 at device_profiler/gems/activesupport-3.0.7/lib/active_support/dependencies.rb:239:in `require' /Users/dave/.rvm/gems/ruby-1.9.2-p180 at device_profiler/gems/activesupport-3.0.7/lib/active_support/dependencies.rb:239:in `block in require' /Users/dave/.rvm/gems/ruby-1.9.2-p180 at device_profiler/gems/activesupport-3.0.7/lib/active_support/dependencies.rb:225:in `block in load_dependency' /Users/dave/.rvm/gems/ruby-1.9.2-p180 at device_profiler/gems/activesupport-3.0.7/lib/active_support/dependencies.rb:596:in `new_constants_in' /Users/dave/.rvm/gems/ruby-1.9.2-p180 at device_profiler/gems/activesupport-3.0.7/lib/active_support/dependencies.rb:225:in `load_dependency' /Users/dave/.rvm/gems/ruby-1.9.2-p180 at device_profiler/gems/activesupport-3.0.7/lib/active_support/dependencies.rb:239:in `require' /Users/dave/.rvm/gems/ruby-1.9.2-p180 at device_profiler/gems/rspec-core-2.6.3/lib/rspec/monkey.rb:1:in `' /Users/dave/.rvm/gems/ruby-1.9.2-p180 at device_profiler/gems/activesupport-3.0.7/lib/active_support/dependencies.rb:239:in `require' /Users/dave/.rvm/gems/ruby-1.9.2-p180 at device_profiler/gems/activesupport-3.0.7/lib/active_support/dependencies.rb:239:in `block in require' /Users/dave/.rvm/gems/ruby-1.9.2-p180 at device_profiler/gems/activesupport-3.0.7/lib/active_support/dependencies.rb:225:in `block in load_dependency' /Users/dave/.rvm/gems/ruby-1.9.2-p180 at device_profiler/gems/activesupport-3.0.7/lib/active_support/dependencies.rb:596:in `new_constants_in' /Users/dave/.rvm/gems/ruby-1.9.2-p180 at device_profiler/gems/activesupport-3.0.7/lib/active_support/dependencies.rb:225:in `load_dependency' /Users/dave/.rvm/gems/ruby-1.9.2-p180 at device_profiler/gems/activesupport-3.0.7/lib/active_support/dependencies.rb:239:in `require' /Users/dave/.rvm/gems/ruby-1.9.2-p180 at device_profiler/gems/rspec-core-2.6.3/lib/rspec/core.rb:103:in `' /Users/dave/.rvm/gems/ruby-1.9.2-p180 at device_profiler/gems/activesupport-3.0.7/lib/active_support/dependencies.rb:239:in `require' /Users/dave/.rvm/gems/ruby-1.9.2-p180 at device_profiler/gems/activesupport-3.0.7/lib/active_support/dependencies.rb:239:in `block in require' /Users/dave/.rvm/gems/ruby-1.9.2-p180 at device_profiler/gems/activesupport-3.0.7/lib/active_support/dependencies.rb:225:in `block in load_dependency' /Users/dave/.rvm/gems/ruby-1.9.2-p180 at device_profiler/gems/activesupport-3.0.7/lib/active_support/dependencies.rb:596:in `new_constants_in' /Users/dave/.rvm/gems/ruby-1.9.2-p180 at device_profiler/gems/activesupport-3.0.7/lib/active_support/dependencies.rb:225:in `load_dependency' /Users/dave/.rvm/gems/ruby-1.9.2-p180 at device_profiler/gems/activesupport-3.0.7/lib/active_support/dependencies.rb:239:in `require' /Users/dave/.rvm/gems/ruby-1.9.2-p180 at device_profiler/bundler/gems/rspec-rails-d3894ad27387/lib/rspec/rails/tasks/rspec.rake:1:in `' /Users/dave/.rvm/gems/ruby-1.9.2-p180 at device_profiler/gems/activesupport-3.0.7/lib/active_support/dependencies.rb:235:in `load' /Users/dave/.rvm/gems/ruby-1.9.2-p180 at device_profiler/gems/activesupport-3.0.7/lib/active_support/dependencies.rb:235:in `block in load' /Users/dave/.rvm/gems/ruby-1.9.2-p180 at device_profiler/gems/activesupport-3.0.7/lib/active_support/dependencies.rb:225:in `block in load_dependency' /Users/dave/.rvm/gems/ruby-1.9.2-p180 at device_profiler/gems/activesupport-3.0.7/lib/active_support/dependencies.rb:596:in `new_constants_in' /Users/dave/.rvm/gems/ruby-1.9.2-p180 at device_profiler/gems/activesupport-3.0.7/lib/active_support/dependencies.rb:225:in `load_dependency' /Users/dave/.rvm/gems/ruby-1.9.2-p180 at device_profiler/gems/activesupport-3.0.7/lib/active_support/dependencies.rb:235:in `load' /Users/dave/.rvm/gems/ruby-1.9.2-p180 at device_profiler/bundler/gems/rspec-rails-d3894ad27387/lib/rspec-rails.rb:10:in `block in ' /Users/dave/.rvm/gems/ruby-1.9.2-p180 at device_profiler/gems/railties-3.0.7/lib/rails/railtie.rb:184:in `call' /Users/dave/.rvm/gems/ruby-1.9.2-p180 at device_profiler/gems/railties-3.0.7/lib/rails/railtie.rb:184:in `each' /Users/dave/.rvm/gems/ruby-1.9.2-p180 at device_profiler/gems/railties-3.0.7/lib/rails/railtie.rb:184:in `load_tasks' /Users/dave/.rvm/gems/ruby-1.9.2-p180 at device_profiler/gems/railties-3.0.7/lib/rails/application.rb:140:in `block in load_tasks' /Users/dave/.rvm/gems/ruby-1.9.2-p180 at device_profiler/gems/railties-3.0.7/lib/rails/application/railties.rb:11:in `each' /Users/dave/.rvm/gems/ruby-1.9.2-p180 at device_profiler/gems/railties-3.0.7/lib/rails/application/railties.rb:11:in `all' /Users/dave/.rvm/gems/ruby-1.9.2-p180 at device_profiler/gems/railties-3.0.7/lib/rails/application.rb:140:in `load_tasks' /Users/dave/.rvm/gems/ruby-1.9.2-p180 at device_profiler/gems/railties-3.0.7/lib/rails/application.rb:77:in `method_missing' /Users/dave/Sites/fiddleback-related/device_profiler/Rakefile:7:in `' /Users/dave/.rvm/gems/ruby-1.9.2-p180 at device_profiler/gems/rake-0.8.7/lib/rake.rb:2383:in `load' /Users/dave/.rvm/gems/ruby-1.9.2-p180 at device_profiler/gems/rake-0.8.7/lib/rake.rb:2383:in `raw_load_rakefile' /Users/dave/.rvm/gems/ruby-1.9.2-p180 at device_profiler/gems/rake-0.8.7/lib/rake.rb:2017:in `block in load_rakefile' /Users/dave/.rvm/gems/ruby-1.9.2-p180 at device_profiler/gems/rake-0.8.7/lib/rake.rb:2068:in `standard_exception_handling' /Users/dave/.rvm/gems/ruby-1.9.2-p180 at device_profiler/gems/rake-0.8.7/lib/rake.rb:2016:in `load_rakefile' /Users/dave/.rvm/gems/ruby-1.9.2-p180 at device_profiler/gems/rake-0.8.7/lib/rake.rb:2000:in `block in run' /Users/dave/.rvm/gems/ruby-1.9.2-p180 at device_profiler/gems/rake-0.8.7/lib/rake.rb:2068:in `standard_exception_handling' /Users/dave/.rvm/gems/ruby-1.9.2-p180 at device_profiler/gems/rake-0.8.7/lib/rake.rb:1998:in `run' /Users/dave/.rvm/gems/ruby-1.9.2-p180 at device_profiler/gems/rake-0.8.7/bin/rake:31:in `' /Users/dave/.rvm/gems/ruby-1.9.2-p180 at device_profiler/bin/rake:19:in `load' /Users/dave/.rvm/gems/ruby-1.9.2-p180 at device_profiler/bin/rake:19:in `
' Line 425 in rubygems.rb attempts to use a string as some type of object that is supposed to have a #specifications method. Running `rvm rubygems current` rolls back to 1.6.2 and the problem disappears. ---------------------------------------------------------------------- >Comment By: Evan Phoenix (evan) Date: 2011-06-02 04:18 Message: This was caused by some code that didn't get properly reverted. I've added a test and fixed it up. Fixed in github:30d6b68 ---------------------------------------------------------------------- Comment By: Andrew Nordman (cadwallion) Date: 2011-06-01 16:06 Message: It looks like it's an issue caused by having rspec-rails and spork together. Steps taken to reproduce: 1. rails new foo 2. edit gemfile to the following: source 'http://rubygems.org' gem 'rails', '3.0.8.rc4' gem 'sqlite3' group :test, :development do gem 'rspec-rails', '2.6.0' gem 'spork', '0.8.5' end 3. bundle install 4. rake -T This will generate the error. When tested against the spork repo master ( gem 'spork', :git => "https://github.com/timcharper/spork.git") it does not error. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-05-31 23:37 Message: No repro... c'mon guys... ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-05-28 23:58 Message: Can you provide some means of repro? And can you also test against spork trunk? ---------------------------------------------------------------------- Comment By: Michael Bleigh (mbleigh) Date: 2011-05-27 23:30 Message: I'm experiencing the same problem and had similar luck fixing it by rolling back RubyGems. It was happening to me when trying to run a rake task in a Rails 3 app. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29232&group_id=126 From noreply at rubyforge.org Thu Jun 2 00:25:56 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 2 Jun 2011 00:25:56 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29191 ] `gem uninstall` complains when the target gem is a development dependency Message-ID: <20110602042557.056FA185838E@rubyforge.org> Bugs item #29191, was opened at 2011-05-09 23:54 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29191&group_id=126 Category: `gem` commands (other) Group: None >Status: Closed Resolution: None Priority: 3 Submitted By: Aaron Patterson (aaronp) >Assigned to: Evan Phoenix (evan) Summary: `gem uninstall` complains when the target gem is a development dependency Initial Comment: When I try to uninstall a gem (for example rake), rubygems tells me about all of the gems that *depend* on that gem. Unfortunately it does not differentiate between development dependencies and regular dependencies. I think it should either a) only look at runtime dependencies, or b) indicate the relationship between the gems (*say* it's a development dep). Here is an example where I try to uninstall rake. Note that rake is simply a dev dep of mocha: [aaron at higgins ~]$ sudo gem uninstall rake Password: You have requested to uninstall the gem: rake-0.8.7 RedCloth-4.2.7 depends on [rake (~> 0.8.7)] cucumber-0.10.2 depends on [rake (>= 0.8.7)] ffi-1.0.7 depends on [rake (>= 0.8.7)] gherkin-2.3.6 depends on [rake (>= 0.8.7)] hoe-2.9.4 depends on [rake (>= 0.8.7)] launchy-0.4.0 depends on [rake (>= 0.8.1)] launchy-0.4.0 depends on [rake (~> 0.8.7)] mocha-0.9.12 depends on [rake (>= 0)] orm_adapter-0.0.4 depends on [rake (>= 0.8.7)] thor-0.14.6 depends on [rake (>= 0.8)] If you remove this gems, one or more dependencies will not be met. Continue with Uninstall? [Yn] n ERROR: While executing gem ... (Gem::DependencyRemovalException) Uninstallation aborted due to dependent gem(s) [aaron at higgins ~]$ gem spec mocha dependencies --- - !ruby/object:Gem::Dependency name: rake prerelease: false requirement: &id001 !ruby/object:Gem::Requirement none: false requirements: - - ">=" - !ruby/object:Gem::Version hash: 3 segments: - 0 version: "0" type: :development version_requirements: *id001 [aaron at higgins ~]$ ---------------------------------------------------------------------- >Comment By: Evan Phoenix (evan) Date: 2011-06-02 04:25 Message: I've changed it so that uninstall uses the same rendering code as 'dep' so that the same output is used! Fixed in github:21c7831 ---------------------------------------------------------------------- Comment By: Aaron Patterson (aaronp) Date: 2011-05-09 23:59 Message: I think you should use the output of `gem dep -R`: [aaron at higgins ~]$ gem dep -R rake Gem rake-0.8.7 Used by RedCloth-4.2.7 (rake (~> 0.8.7, development)) cucumber-0.10.2 (rake (>= 0.8.7, development)) ffi-1.0.7 (rake (>= 0.8.7)) gherkin-2.3.6 (rake (>= 0.8.7, development)) hoe-2.9.4 (rake (>= 0.8.7)) launchy-0.4.0 (rake (>= 0.8.1)) launchy-0.4.0 (rake (~> 0.8.7, development)) mocha-0.9.12 (rake (>= 0, development)) orm_adapter-0.0.4 (rake (>= 0.8.7, development)) thor-0.14.6 (rake (>= 0.8, development)) [aaron at higgins ~]$ ---------------------------------------------------------------------- Comment By: Aaron Patterson (aaronp) Date: 2011-05-09 23:57 Message: Also, here is my gem env output: RubyGems Environment: - RUBYGEMS VERSION: 1.8.1 - RUBY VERSION: 1.8.7 (2009-06-12 patchlevel 174) [universal-darwin10.0] - INSTALLATION DIRECTORY: /Library/Ruby/Gems/1.8 - RUBY EXECUTABLE: /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/ruby - EXECUTABLE DIRECTORY: /usr/bin - RUBYGEMS PLATFORMS: - ruby - universal-darwin-10 - GEM PATHS: - /Library/Ruby/Gems/1.8 - /Users/aaron/.gem/ruby/1.8 - GEM CONFIGURATION: - :update_sources => true - :verbose => true - :benchmark => false - :backtrace => false - :bulk_threshold => 1000 - :sources => ["http://gems.rubyforge.org/"] - "gemcutter_key" => "********************************" - "install" => "--format-executable --no-user-install" - "update" => "--format-executable --no-user-install" - REMOTE SOURCES: - http://gems.rubyforge.org/ ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29191&group_id=126 From noreply at rubyforge.org Thu Jun 2 11:50:56 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 2 Jun 2011 11:50:56 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29176 ] Scary warnings are scaring helpless developers who can't do a thing about it Message-ID: <20110602155056.5A42F1D780D5@rubyforge.org> Bugs item #29176, was opened at 2011-05-06 13:07 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29176&group_id=126 Category: `gem` commands (other) Group: None Status: Open Resolution: None Priority: 3 Submitted By: Alex Chaffee (alexch) Assigned to: Ryan Davis (zenspider) Summary: Scary warnings are scaring helpless developers who can't do a thing about it Initial Comment: Suddenly anyone using "gem" is seeing many repetitions of lines like this: NOTE: Gem::Specification#default_executable= is deprecated with no replacement. It will be removed on or after 2011-10-01. Gem::Specification#default_executable= called from /Users/chaffee/.rvm/gems/ruby-1.9.2-p0/specifications/thin-1.2.7.gemspec:10. Many of my students are completely freaking out since something that's supposed to just work -- e.g. "gem install rails" or "gem list"-- is now spewing a huge amount of scary noise about things which are currently working just fine, and which they have no ability to affect. Even developers with the acumen to be able to read, understand, and react to these messages are wasting time googling, often fruitlessly, since even if they find Ryan's blog post, and run "gem pristine --all --no-extensions", it doesn't make all the warnings disappear. Here's my suggested fix, in three independent parts. 1. Stop repeating the same message again and again; instead set a global flag (already_scared_user?) and STFU if it happens for a different gem 2. Put the advice about running "gem pristine --all --no-extensions" in the error message instead of forcing people to google to find a workaround 3. Before the warning, try to rewrite the offending gemfile yourself, as if the user had run "gem pristine". If the rewrite fails, only then scare the user. And please remember that the "gem" command is the user interface to the entire world of Ruby development, for people of all experience levels. You have a responsibility not to scare off our friends, new and old. ---------------------------------------------------------------------- >Comment By: Chad Woolley (thewoolleyman) Date: 2011-06-02 08:50 Message: https://github.com/rubygems/rubygems/pull/66#issuecomment-1281426 ---------------------------------------------------------------------- Comment By: William Denniss (divzero) Date: 2011-05-25 04:23 Message: +1 that it would be good to reduce the 'scaryness'/volume of these warnings. I was setting up rails on a new machine for a colleague today. He saw all the errors and assumed the install was broken until I assured him it wasn't. I think it's good to have deprecation warnings ??but having so many, and for something that that needs to be fixed by the gem maintainers and not end-user-developers, doesn't seem to help. We were all 'helpless developers' once don't forget! Pull request #59 seems to fit the bill. ---------------------------------------------------------------------- Comment By: Chad Woolley (thewoolleyman) Date: 2011-05-24 17:05 Message: We are now getting duplicate pull requests in addition to Alex's (https://github.com/rubygems/rubygems/pull/66#issuecomment-1232323). May we please have the active maintainers weigh in on whether or not Alex's pull request can or cannot be merged? We can probably arrange to discuss on IRC if that is necessary... ---------------------------------------------------------------------- Comment By: Chad Woolley (thewoolleyman) Date: 2011-05-22 16:38 Message: Is there any reason not to merge Alex's patch? https://github.com/rubygems/rubygems/pull/59 He stepped up and wrote some code to make the situation better, and had it code-reviewed by Evan. Can we at least merge that or give feedback? ---------------------------------------------------------------------- Comment By: Jordan Sissel (jordansissel) Date: 2011-05-22 14:06 Message: I suspect this ticket not going to be resolved and is falling on deaf ears the ratio of "suck it up" responses to the "this sucks, please help" comments. If this is thie case, please just close this ticket with a resolution of whatever rubyforge's equivalent of "won't fix" with relevant links to workarounds. ---------------------------------------------------------------------- Comment By: Beoran Aegul (beoran) Date: 2011-05-22 01:10 Message: +1 for solution 1. Running gem pristine broke my rubygems, so I think it's a non-solution. I understand the need to clean up rubygems, but trying to force the whole ruby world to upgrade their gems specs so suddenly is not a good idea, IMHO. Not to mention many useful gems out there that are not maintained actively anymore. Kind Regards, B. ---------------------------------------------------------------------- Comment By: Alex Chaffee (alexch) Date: 2011-05-18 13:45 Message: Ping. My patch https://github.com/rubygems/rubygems/pull/59 doesn't change the inner workings at all, just improves the way deprecations are reported. Given that the idea is to get people to pay attention to them, it seems like people are more likely to pay attention to an organized list than a disorganized flood (especially since the list removes duplicates). Evan has code reviewed the patch and I implemented all his suggestions. ---------------------------------------------------------------------- Comment By: Luis Lavena (luislavena) Date: 2011-05-12 14:58 Message: Ryan, I think I did these steps before 1.8.2, I haven't tried it yet. Also since all my gems are fixed now, can't test again :-) ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-05-12 14:19 Message: Luis, unless I'm not understanding the rvm gem setup correctly, there is no need to do the `rvm use` line anymore. pristine had a bug with multiple repos that was fixed in 1.8.2. ---------------------------------------------------------------------- Comment By: Scott Tadman (tadman) Date: 2011-05-12 09:44 Message: Thanks, Luis, for that tip. I guess that means to upgrade rubygems the user is obligated to: rvmsudo bash gem pristine --all rvm use 1.9.2-p180 at global gem pristine --all Where this is documented other than this ticket, I have no idea. If I hadn't spent hours trying to remedy this, I would've just reverted to gem 1.6.0 and called it a day. If the intent of these warnings is to get people to upgrade, I have a feeling the opposite thing will occur. ---------------------------------------------------------------------- Comment By: Luis Lavena (luislavena) Date: 2011-05-12 08:22 Message: @Scott Tadman: gem pristine with "--no-extensions" will not fix gems that have extensions, that includes rcov, json, perftools. For that, you need "gem pristine" alone. As for rake, it is placed in the global namespace of RVM, so you need to switch to that namespace and correct it: rvm use 1.9.2-p180 at global gem pristine rake Then switch to your normal gemset. ---------------------------------------------------------------------- Comment By: Scott Tadman (tadman) Date: 2011-05-12 08:11 Message: Further investigation reveals that Jeweler's generated .gemspec file is affected by the version of rubygems installed, and that if building against a newer rubygems it will not put in the default_executable= call, so at least that much is fixed. However, the catch-22 here is that you need to build using a newer version of rubygems, which because of all the crazy warnings you get, I'm sure a lot of developers would avoid, instead reverting to an earlier, safer version. I have run gem pristine --all --no-extensions over six times on an OS X rvm-based Ruby 1.9.2 set of system gems and I'm still getting warnings. The first pass removed most, the second some, and the rest virtually none. I'm not sure why this needs to be run more than once in the first place, nor why this is the responsibility of the user. Now anything that even touches rubygems ends up getting lit up with warnings, the final few of which appear to be the most stubborn: NOTE: Gem::Specification#default_executable= is deprecated with no replacement. It will be removed on or after 2011-10-01. Gem::Specification#default_executable= called from /opt/local/rvm/gems/ruby-1.9.2-p180 at global/specifications/rake-0.8.7.gemspec:10. NOTE: Gem::Specification#default_executable= is deprecated with no replacement. It will be removed on or after 2011-10-01. Gem::Specification#default_executable= called from /opt/local/rvm/gems/ruby-1.9.2-p180/specifications/json-1.5.1.gemspec:10. NOTE: Gem::Specification#default_executable= is deprecated with no replacement. It will be removed on or after 2011-10-01. Gem::Specification#default_executable= called from /opt/local/rvm/gems/ruby-1.9.2-p180/specifications/perftools.rb-0.5.6.gemspec:10. NOTE: Gem::Specification#default_executable= is deprecated with no replacement. It will be removed on or after 2011-10-01. Gem::Specification#default_executable= called from /opt/local/rvm/gems/ruby-1.9.2-p180/specifications/rcov-0.9.9.gemspec:11. (in /Users/tadman/git/pigeon) It is worrying that the pristine operation not only produces ~500KB of warnings when processing its various things which buries any actual errors in the process. Maybe there's a reason why these gems can't be pristined properly, but it gets lost in the hurricane of warnings. ---------------------------------------------------------------------- Comment By: Mike Bethany (mikbe) Date: 2011-05-12 00:36 Message: The deprecation warnings made it virtually impossible to work. Every time autotest ran I would have a screen full of gobbledygook I had to sort through, very annoying. I wrote Chicken Little to disable the deprecation warnings just for the two major offenders. You can install the gem with: `gem install chicken_little` then run it `chicken_little install` You can also just go in and edit the RubyGems specification.rb file yourself and comment out those lines. Source: https://github.com/mikbe/chicken_little RubyGems: https://rubygems.org/gems/chicken_little P.S. RubyGems 1.8.2 seems to be broken in Ubuntu 10.10. Funny enough in the specification.rb file at line 277. Though it seems to be OK in OS X 10.6.7. ---------------------------------------------------------------------- Comment By: Alex Chaffee (alexch) Date: 2011-05-11 16:25 Message: I've gone ahead and made a patch. My fork of rubygems still prints out warnings, but after the first warning, it buffers up all remaining warnings and then emits them at_exit in a somewhat nicer report format, like this: Some of your installed gems called deprecated methods. See http://blog.zenspider.com/2011/05/rubygems-18-is-coming.html for background. Use 'gem pristine --all' to fix or 'rubygems update --system 1.7.2' to downgrade. TestDeprecate::Thing#foo is deprecated; use bar instead. It will be removed on or after 2099-03-01. called from /Users/chaffee/dev/rubygems/test/rubygems/test_deprecate.rb:174 called from /Users/chaffee/dev/rubygems/test/rubygems/test_deprecate.rb:175 called from /Users/chaffee/dev/rubygems/test/rubygems/test_deprecate.rb:177 TestDeprecate::Thing#goo is deprecated; use bar instead. It will be removed on or after 2099-04-01. called from /Users/chaffee/dev/rubygems/test/rubygems/test_deprecate.rb:176 I also pulled in the "--no-warnings" patch, but set the default back to "show all warnings" (i.e. skip=false). https://github.com/alexch/rubygems/commit/5572c2c1bb88e2e1b55b8d62 3fe4ef58a954c2a1 ---------------------------------------------------------------------- Comment By: Scott Tadman (tadman) Date: 2011-05-11 11:06 Message: Part of this problem is that Jeweler, a gem used by many authors to build their gems, inserts the default_executable= line in all the .gemspec files it produces. This is something done without the knowledge of the authors, and as one, I'm not even sure how to turn it off. I'll have to do more research. In the mean-time I need to live with the guilt and shame of causing warnings for everyone using anything I've made. I do want to keep up to date. I use Ruby 1.9.2 and the latest everything for new projects, but there are many legacy applications I'm involved with that for reasons of budget, dependency hell, or otherwise, are constrained to specific older versions. What I'm asking is why methods can't be deprecated by rendering them non-functional instead of causing things to explode by calling methods that no longer exist. It is common practice amongst UNIX shell utilities to have non-functional arguments for this very reason. I'm not saying to support the API, but at least make it mostly compatible with the newest spec even if it may not perform exactly as intended. For instance, most browsers don't support the tag, but they also don't refuse to render the page because of a lack of support. Once again, these are not my "decrepit needs", but rather the fact that there are hundreds if not thousands of gems out there with this mostly useless call to default_executable= as inserted by Jeweler and others that could be harmlessly ignored. I will post another ticket relating to the warnings later if I can replicate it. I have mostly fixed the issue using the pristine option which should be advertised more clearly or, better yet, done automatically when gem is updated to the newest release. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-05-11 02:02 Message: Scott, Please file a ticket with details and, if possible, reproduction steps showing that rolling back to 1.7.2 still has deprecation warnings that were added to 1.8.0. If it isn't too much to ask, please file a ticket with details and, if possible, reproduction steps showing "literally, 4000+ lines of warnings when running ordinary rake tasks" after running `gem pristine --all --no-extensions`. Do note that I suspect there is a bug in `gem pristine` in scenarios like using rvm w/ multiple gem directories... I don't have a repro for that yet. Finally, the majority of these deprecations are created _by_ rubygems in gemspecs and are fixable _by_ rubygems (pristine bugs notwithstanding)... Those warnings that are left afterwards represent real usage of methods that ARE going away. You state that you're intentionally running old gems on your apps but you insist on updating rubygems & bundler... You're going to update to a version that doesn't have the implementation one of your decrepit needs. What is your plan for that? Do you really think it reasonable that we should keep around API supporting everything all the way back to 2004? I'm sorry, but that just doesn't seem sane to me. We have to move on, even if you won't. ---------------------------------------------------------------------- Comment By: Scott Tadman (tadman) Date: 2011-05-10 21:37 Message: This issue is driving me berserk. I've pristined, I've rolled back to 1.7.2 like the Germans retreating from Russia and still I'm getting nagged and hassled. When something like default_executable is specified in default gemspec files that Jeweler produces and other templates that many have used to build out their gemspecs, it does seem like a bit of a nuisance. Maybe it's better to rescind support for it and turn it into a method that does nothing simply for compatibility reasons. Document the method as deprecated and non-functional for the curious. Lobby to get it removed from examples and places like Jeweler. I have applications with dozens of deliberately old versions of gems because the associated applications aren't up to date and upgrading causes problems. The one thing I do want to keep up to date is support utilities like gem and bundler, though, and getting, literally, 4000+ lines of warnings when running ordinary rake tasks is not helping. Even if I nagged and hassled every single gem builder, and seriously, I have nagged many about Ruby 1.9 issues, this still wouldn't matter because I simply have older versions of gems installed that cannot be patched without altering the space-time continuum. This is basically condemning me to using an antiquated version of gem so long as I have even one squeaky wheel in the whole system, as a single out of date gem will produce warnings for every gem related operation. When installing a new gem, if strictly necessary, it could say that the .gemspec is out of date and should be updated while hinting at the obscure pristine command as to how that might remedy it. I have wildly different versions of gem installed on my systems, but it's as if every time I go to update to the latest I get slapped in the face with something like this. I honestly wonder how other people have fared. After a lot of fussing about, experimenting with different approaches and attempting to be as unobtrusive as possible, I have come up with a patch that enables Deprecate.skip by default and also allows the setting to be toggled on or off as desired using the --warnings or --no-warnings options for install. After inspecting the implementation of this, which appears to have erupted into the root namespace as the module Deprecate, and without any sort of unit test, I have inverted the default because warnings are generated before command options are processed and there does not appear to be any other way. Patch: https://gist.github.com/965921 ---------------------------------------------------------------------- Comment By: Stephen Bannasch (stepheneb) Date: 2011-05-10 20:13 Message: For now I'm using this solution: gem update --system 1.7.2 Thanks Luis -- I didn't remember how easy it was to downgrade RubyGems. After running: gem pristine --all --no-extensions -- running a single spec test In my rails 2.3.11 project with RubyGems 1.8.1 generates 317 lines of warnings before I see the 10 lines of results: https://gist.github.com/965850 It's certainly annoying enough to get me to plan to fix my gem (jnlp) but my one gem is just a tiny bit of the noise in general. ---------------------------------------------------------------------- Comment By: Jordan Sissel (jordansissel) Date: 2011-05-10 18:36 Message: FWIW, I support deprecations, but these warning messages are going to users, not developers. And that sucks. For example, all my ruby nagios alerts are filled, now, with pointless warnings about libraries my code is *not* using. So many warnings, in fact, that the test code's output is lost. This warning should pop up when developers run 'gem build foo.gemspec' and no other time. Why? Consider a user who has code that relies on rake '0.8.0' explicitly. You can't actually fix 'rake 0.8.0' on rubygems.org because you can't overwrite an existing release (for good reason). So now, for eternity, this user is stuck with warning messages. ---------------------------------------------------------------------- Comment By: Alex Chaffee (alexch) Date: 2011-05-10 10:55 Message: Chad - A two-line warning per gem would still be super noisy. One compromise would be to queue up a list of offending gems per warning and then emit them all on_exit in a single line. As for patches, as I said before, I'd be happy to spend my time working on that, but not until I get the goahead from a member of the core team (especially considering that first comment). ---------------------------------------------------------------------- Comment By: Scott Tadman (tadman) Date: 2011-05-10 09:26 Message: I just "upgraded" gem and now I'm greeted with over a thousand lines of warnings, nearly one for every gem I have installed on my system. It doesn't just warn for gems I use, but any gems I might happen to have that are out of date. The message itself is meaningless as there's really nothing I can do about it, and further, it doesn't seem like ignoring that directive instead of complaining about it would have much of an effect on the end user. Since when is it the responsibility of gem users to hassle gem builders into compliance? Why can't the gem build operation give the builder a hard time instead? Why can't rubygems.org reject the gem out of protest? As a note, I'm also getting a kabillion identical warnings apparently from rubygems itself: Gem::SourceIndex#add_spec called from /opt/local/rvm/rubies/ree-1.8.7-2011.03/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:127. NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It will be removed on or after 2011-11-01. Gem::SourceIndex#add_spec called from /opt/local/rvm/rubies/ree-1.8.7-2011.03/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:127. NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It will be removed on or after 2011-11-01. Gem::SourceIndex#add_spec called from /opt/local/rvm/rubies/ree-1.8.7-2011.03/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:127. NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It will be removed on or after 2011-11-01. Gem::SourceIndex#add_spec called from /opt/local/rvm/rubies/ree-1.8.7-2011.03/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:127. NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It will be removed on or after 2011-11-01. Gem::SourceIndex#add_spec called from /opt/local/rvm/rubies/ree-1.8.7-2011.03/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:127. NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It will be removed on or after 2011-11-01. Gem::SourceIndex#add_spec called from /opt/local/rvm/rubies/ree-1.8.7-2011.03/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:127. NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It will be removed on or after 2011-11-01. Gem::SourceIndex#add_spec called from /opt/local/rvm/rubies/ree-1.8.7-2011.03/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:127. NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It will be removed on or after 2011-11-01. Gem::SourceIndex#add_spec called from /opt/local/rvm/rubies/ree-1.8.7-2011.03/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:127. NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It will be removed on or after 2011-11-01. ---------------------------------------------------------------------- Comment By: Chad Woolley (thewoolleyman) Date: 2011-05-08 11:43 Message: I agree, it would be nice if the deprecation warning were once per gem (NOT once for all gems as Alex suggested; that would defeat the purpose of getting people to complain to gem authors to fix their specs) However, I don't see any patches or even failing tests attached to this ticket yet... ---------------------------------------------------------------------- Comment By: Loren Segal (lsegal) Date: 2011-05-08 09:40 Message: Ryan, I'm not too sure if you read the entirety of my message. Just in case, I'll summarize again: 1. I agree that having warnings telling developers to update their APIs is good. I believe I said that. (Feel free to check) 2. The issue in this report is not about whether the warnings should exist or not, because everybody here agrees they should. The issue is how often they need to be printed. Given that I am suggesting the same fix as Alex, I don't see how this falls out of the scope of the ticket. 3. My feedback was not (entirely) a "me too". I am simply trying to provide extra information regarding the breadth of this issue that others might not be aware of; specifically that `gem pristine --all` is not a complete solution to this issue, at least it does not guarantee the hiding of all warning *spam* (remember, not arguing about first-time warnings, but complete page-spam). As far as I know, that problem was not yet discussed. I'm of the opinion that all relevant information should be provided with a bug report. There's no need to jump down users throats for providing extra information, so please try to use your indoor voice. 3. I don't see why modifying the warnings to show once (per method) needs to be controversial. It seems like quite a simple and reasonable change, at least to me. Is it not reasonable to you? Why not? Finally, as far as I know, open source relies on feedback from the community; certainly a tool that is widely used and part of Ruby's standard library deserves feedback from all of the community. Telling users that they are not allowed to voice their opinion on an open ticket simply does not compute. I'm therefore politely declining your invitation to "get off this ticket". Though, I suppose this should have prefaced the response with this note instead. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-05-08 01:56 Message: No worries. ---------------------------------------------------------------------- Comment By: Justin Collins (presidentbeef) Date: 2011-05-07 23:57 Message: Sorry, my mistake. I didn't notice that gem was called out specifically. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-05-07 23:54 Message: Justin, As described at http://blog.zenspider.com/2011/05/rubygems-18-is-coming.html and elsewhere, rake is one of those unfortunate gems that explicitly uses the deprecated API in their gemspec. Please file a bug on the rake bug tracker. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-05-07 23:53 Message: Loren, Get off this ticket. Everything you just described falls outside of the scope of this ticket. Specifically: "helpless developers". The point of having deprecations at all is to get those "hundreds" of libraries that use deprecated API to update their code. If you want to "me too", then yippie... but your hyperbole isn't a "me too" it is a completely separate issue (and one I will more readily reject). ---------------------------------------------------------------------- Comment By: Justin Collins (presidentbeef) Date: 2011-05-07 23:19 Message: I did a fresh install of 1.9.2 with rvm, then upgraded Ruby Gems. The only gem installed was "rake", and after running "gem pristine --all", "gem pristine --all --no-extensions", and "gem pristine rake", I still get the following error: NOTE: Gem::Specification#default_executable= is deprecated with no replacement. It will be removed on or after 2011-10-01. Gem::Specification#default_executable= called from /home/justin/.rvm/gems/ruby-1.9.2-p180 at global/specifications/rake-0.8.7.gemspec:10. ---------------------------------------------------------------------- Comment By: Loren Segal (lsegal) Date: 2011-05-07 22:40 Message: I have to agree with the severity of this issue. The problem is unfortunately not just limited to the `gem` binary. Any library making use of deprecated APIs will also get these warnings ad-infintum, so gem pristinie --all doesn't solve this issue, only small one part of it. For example, any gem that makes use of SourceIndex will see these deprecation warnings on each usage. There are currently hundreds of libraries that make use of this class, as per my latest search on codesearch: http://codesearch.google.com/codesearch?q=SourceIndex+lang:ruby and http://codesearch.google.com/codesearch?q=Gem.source_index+lang%3Aruby You might get lucky and just see a few of these warnings, but if the method is called within a loop, RubyGems will not be forgiving, and spam you many, many, times (see http://codesearch.google.com/codesearch/p?hl=en#L18QHnAzSFA/bin/minigem&q=Gem.source_index%20lang:ruby&sa=N&cd=46&ct=rc for just one random example). In some cases, this output may even render the lib/tool completely unusable, especially if it relies heavily on console output. Because of that possibility, an otherwise innocuous (and transitional) warning can become a "severe" compatibility bug. Just like Alex, I'm all for warnings, but I foresee a lot of developers scrambling to provide fixes for their users in the coming months, especially in the cases where their tools start scrolling pages of warnings just because of one method call. I'm not sure devs or users will be too happy about this. Fortunately the fix is simple, as Alex pointed pointed out. I think it would be sensible to add the suggested "already_scared_user?" flag; it can probably be done on a per method name granularity. Given that all of the deprecations are wrapped inside a Deprecation module AFAIK(?), this should be pretty simple to add. ---------------------------------------------------------------------- Comment By: Luis Lavena (luislavena) Date: 2011-05-06 15:04 Message: Which gem was not solved by gem pristine --all? please provide complete output, we can't help without the output. As for drowning on this issue: revert back to 1.7.2 There is no easy way to solve existing gem specifications without doing gem pristine --all And we can't help solve the others without people telling us which ones didn't get fixed for us to look at *why*. So, I know were are you coming from, heck, I work on Windows, what more weird scenario for failures could be than that? And even so, gem pristine --all solved all the issues. Help us help you. ---------------------------------------------------------------------- Comment By: Alex Chaffee (alexch) Date: 2011-05-06 14:41 Message: Luis - thanks, "gem pristine -all" has fixed most -- but still not quite all -- of the messages. Warnings are indeed good, but only until they become noise. That is extra bad since it can drown out other important information, especially for less experienced people who are mystified by everything coming down on the console. One reason I'm concerned about this is that tonight in two different cities we're doing a Railsbridge Ruby For Women Workshop Install Fest, and most of the students won't understand what's going on, and the volunteers may not either. This will add chaos to an already chaotic and frustrating session. Not your problem, I know, but I wanted you to know where I'm coming from. ---------------------------------------------------------------------- Comment By: Luis Lavena (luislavena) Date: 2011-05-06 13:38 Message: gem pristine --all --no-extensions will fix the gems that do not have extensions You need to do gem pristine -all, but that will not accept parameters for each gem. In my case I didn't require additional parameters to each gem so a simple gem pristine --all solved all the warnings. Warnings are good, and as always, you can rollback to previous versions if you find it doesn't work for you: gem update --system 1.7.2 ---------------------------------------------------------------------- Comment By: Alex Chaffee (alexch) Date: 2011-05-06 13:27 Message: I wasn't trying to be inflammatory. This is a real problem, wasting the real time of real people across the world. And I'd be happy to submit a patch but somehow it doesn't seem likely you'd accept it. ---------------------------------------------------------------------- Comment By: Erik Hollensbe (erikh) Date: 2011-05-06 13:22 Message: Really? Don't you have anything better to do than to post inflammatory shit to this tracker? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29176&group_id=126 From noreply at rubyforge.org Fri Jun 3 14:15:09 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 3 Jun 2011 14:15:09 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29249 ] Can't downgrade to 1.37 from 1.8.5 Message-ID: <20110603181509.9E1B018583AA@rubyforge.org> Bugs item #29249, was opened at 2011-06-03 15:15 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29249&group_id=126 Category: `gem install` command Group: None Status: Open Resolution: None Priority: 3 Submitted By: Luis Lavena (luislavena) Assigned to: Evan Phoenix (evan) Summary: Can't downgrade to 1.37 from 1.8.5 Initial Comment: User following the instructions form UPGRADING was not able to downgrade properly under Ruby 1.9.2: http://help.rubygems.org/discussions/problems/617-downgrading-rubygems-from-185-to-137-gives-an-error Find here a gist of the error: https://gist.github.com/1006834 Either the issue need to be corrected or the documentation needs to reflect the limitation. Thank you. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29249&group_id=126 From noreply at rubyforge.org Fri Jun 3 15:48:07 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 3 Jun 2011 15:48:07 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Patches-29250 ] Please backport r31914 and r31915 from Ruby trunk Message-ID: <20110603194808.9F5AE1678326@rubyforge.org> Patches item #29250, was opened at 2011-06-03 16:48 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=577&aid=29250&group_id=126 Category: other Group: None Status: Open Resolution: None Priority: 3 Submitted By: Luis Lavena (luislavena) Assigned to: Evan Phoenix (evan) Summary: Please backport r31914 and r31915 from Ruby trunk Initial Comment: Hello. Find attached a patch that backports the modifications done by Yui NARUSE to RubyGems code in trunk. Thread is [ruby-core:36720]. Issue discussed is #4445: http://redmine.ruby-lang.org/issues/4455 This does not apply to master branch of RubyGems, so the patch is against 1.8 branch. Thank you. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=577&aid=29250&group_id=126 From halostatue at gmail.com Fri Jun 3 21:03:38 2011 From: halostatue at gmail.com (Austin Ziegler) Date: Fri, 3 Jun 2011 21:03:38 -0400 Subject: [Rubygems-developers] Proposal for signing gems In-Reply-To: <4DDEEFC3.9050608@grant-olson.net> References: <4DDEC026.7020207@grant-olson.net> <4DDED563.9080201@grant-olson.net> <9169DB74B10149F8A69DF991B7FABB1A@gmail.com> <4DDEEFC3.9050608@grant-olson.net> Message-ID: On Thu, May 26, 2011 at 8:26 PM, Grant Olson wrote: > 1) Is the gpg requirement still a dealbreaker in this scenario? I would consider the requirement of any external binary to be a dealbreaker, especially for when I need to deploy gems on Windows. -a -- Austin Ziegler ? halostatue at gmail.com ? austin at halostatue.ca http://www.halostatue.ca/ ? http://twitter.com/halostatue From drbrain at segment7.net Fri Jun 3 21:43:26 2011 From: drbrain at segment7.net (Eric Hodel) Date: Fri, 3 Jun 2011 18:43:26 -0700 Subject: [Rubygems-developers] Proposal for signing gems In-Reply-To: <4DDEEFC3.9050608@grant-olson.net> References: <4DDEC026.7020207@grant-olson.net> <4DDED563.9080201@grant-olson.net> <9169DB74B10149F8A69DF991B7FABB1A@gmail.com> <4DDEEFC3.9050608@grant-olson.net> Message-ID: <6C54E1A6-65B0-4D52-A86E-E3C7F54949FF@segment7.net> On May 26, 2011, at 5:26 PM, Grant Olson wrote: > Fair enough. I'll look into exactly how hairy this will be. > > But for now, let's go under the assumption that I write a plugin for > rubygems. Not part of the base system. This plugin allows you to sign > and verify gems, and does require a working gpg installation. Only > people who care about software verification install it and use it. And > then in the year 2013 or 2038 or whatever, there's a pure ruby version > of the back end crypto stuff and we merge the code with rubygems. > > 1) Is the gpg requirement still a dealbreaker in this scenario? RubyGems must either be contained within RubyGems or Ruby. If Ruby had a PGP/GPG library this would be no longer be a dealbreaker (hint). > 2) Does rubygems do any verification of the contents? Will a few extra > files in the main .tgz flag the gem as invalid? The structure of a plain gem is: blah.gem data.tar.gz metadata.gz The structure of a signed gem (with current code) is: blah.gem data.tar.gz data.tar.gz.sig metadata.gz metadata.gz.sig You could put whatever other files in there you wanted. > 3) Is there interest in a simulated CA at a site like rubygems, as > described in the original post? Yes We could do something lazier too, IIRC `gem push` uses SSL to upload the gem, so rubygems.org could simply sign any gems with its own cert. No need for a CA or any of that stuff. (This proposal is overly simplistic currently). From kgo at grant-olson.net Fri Jun 3 23:16:27 2011 From: kgo at grant-olson.net (Grant Olson) Date: Fri, 03 Jun 2011 23:16:27 -0400 Subject: [Rubygems-developers] Proposal for signing gems In-Reply-To: <6C54E1A6-65B0-4D52-A86E-E3C7F54949FF@segment7.net> References: <4DDEC026.7020207@grant-olson.net> <4DDED563.9080201@grant-olson.net> <9169DB74B10149F8A69DF991B7FABB1A@gmail.com> <4DDEEFC3.9050608@grant-olson.net> <6C54E1A6-65B0-4D52-A86E-E3C7F54949FF@segment7.net> Message-ID: <4DE9A38B.2070503@grant-olson.net> On 6/3/2011 9:43 PM, Eric Hodel wrote: > On May 26, 2011, at 5:26 PM, Grant Olson wrote: > >> 3) Is there interest in a simulated CA at a site like rubygems, as >> described in the original post? > > Yes > > We could do something lazier too, IIRC `gem push` uses SSL to upload the gem, so rubygems.org could simply sign any gems with its own cert. No need for a CA or any of that stuff. (This proposal is overly simplistic currently). Do you mean your proposal or mine is simplistic? It actually would be nice if rubygems signed the gem on push, if it somehow verified the gem's authenticity when it was uploaded, above and beyond the username/password check. From my perspective, that would still introduce some problems: Does rubygems.org deliver the certificate through a new remote API call, or does it embed the sig in the uploaded gem? Either API change seems problematic, and would require integration with rubygems (the gem) as well. Signing a user's certificate could happen without modifiying the core rubygems.org distribution system as it exists now. Anyway, I did create a gem called rubygems-openpgp that allows you to sign and verify gems. I'm planning to add functionality to make signing and building a single command. I'd like to make verifying and installing a single command, but it doesn't look like there will be an easy way for me to hook into the system between the fetch and install phases. It also looks problematic to hook into any gem dependencies that automatically get downloaded, so that they are verified as well. Anyway, if anyone wants to take a look, my plugin is on rubygems as well as gihub: gem install rubygems-openpgp https://github.com/grant-olson/rubygems-openpgp -- Grant From drbrain at segment7.net Sat Jun 4 15:57:38 2011 From: drbrain at segment7.net (Eric Hodel) Date: Sat, 4 Jun 2011 12:57:38 -0700 Subject: [Rubygems-developers] Releasing gems for ruboto (JRuby on Android) In-Reply-To: References: <3D1B361D-C145-4F2D-81C3-401FE973A752@datek.no> <16B69018B2894997A0344867B26E3044@gmail.com> <56C1C8E2-E846-4354-BF89-69DCC631B180@datek.no> <63E1BD9318F6470E9B4940C87E775361@gmail.com> Message-ID: <87CA885C-6527-4626-94A0-7AEDF075A5B9@segment7.net> On May 31, 2011, at 9:40 AM, Uwe Kubosch wrote: >>> I am a developer in the Ruboto project. We seek information on how to enable users of Ruboto to both relase Ruboto-specific gems and comsume gems in Ruboto projects. I was unable to find a mailing list for RubyGems users. >> I'm not clear on what you mean by this, but you can certainly set the platform for a gem to be whatever platform is reported by ruby on android (likely java because of jruby), in which case they'll be restricted to installing on that platform. > > OK, so setting spec.platform = 'ruboto' in the gemspec will make a gem that will not install on other platforms. I will try this. I recommend setting it to the appropriate entry from `gem env`s platform section: Plain ruby has this: - RUBYGEMS PLATFORMS: - ruby - universal-darwin-10 Rubinius has a rubinius-specific platform: - RUBYGEMS PLATFORMS: - ruby - x86_64-darwin-10 - x86_64-rubinius-1.2 Setting it to just "ruboto" will not do what you think: $ ruby19 -e 'p Gem::Platform.new "ruboto"' # Usually you want to set the platform to Gem::Platform::CURRENT but that will only work when you're building the gem on the same platform the gem will run on. ? I can help you best with the output of `gem env` from ruboto. From uwe at datek.no Sat Jun 4 16:27:14 2011 From: uwe at datek.no (Uwe Kubosch) Date: Sat, 4 Jun 2011 20:27:14 +0000 Subject: [Rubygems-developers] Releasing gems for ruboto (JRuby on Android) In-Reply-To: <87CA885C-6527-4626-94A0-7AEDF075A5B9@segment7.net> References: <3D1B361D-C145-4F2D-81C3-401FE973A752@datek.no> <16B69018B2894997A0344867B26E3044@gmail.com> <56C1C8E2-E846-4354-BF89-69DCC631B180@datek.no> <63E1BD9318F6470E9B4940C87E775361@gmail.com> <87CA885C-6527-4626-94A0-7AEDF075A5B9@segment7.net> Message-ID: <0B30AAB5-02DD-41D3-8F51-92154E519A96@datek.no> On 2011-06-04, at 21:57, Eric Hodel wrote: > On May 31, 2011, at 9:40 AM, Uwe Kubosch wrote: >>>> I am a developer in the Ruboto project. We seek information on how to enable users of Ruboto to both relase Ruboto-specific gems and comsume gems in Ruboto projects. I was unable to find a mailing list for RubyGems users. >>> I'm not clear on what you mean by this, but you can certainly set the platform for a gem to be whatever platform is reported by ruby on android (likely java because of jruby), in which case they'll be restricted to installing on that platform. >> >> OK, so setting spec.platform = 'ruboto' in the gemspec will make a gem that will not install on other platforms. I will try this. > > I recommend setting it to the appropriate entry from `gem env`s platform section: > > Plain ruby has this: > > - RUBYGEMS PLATFORMS: > - ruby > - universal-darwin-10 > > Rubinius has a rubinius-specific platform: > > - RUBYGEMS PLATFORMS: > - ruby > - x86_64-darwin-10 > - x86_64-rubinius-1.2 > > Setting it to just "ruboto" will not do what you think: > > $ ruby19 -e 'p Gem::Platform.new "ruboto"' > # > > Usually you want to set the platform to Gem::Platform::CURRENT but that will only work when you're building the gem on the same platform the gem will run on. > > ? I can help you best with the output of `gem env` from ruboto. Thanks! Ruboto has no command line for running the gem command. What library call does "gem env" result in? -- Uwe Kubosch Systems Developer Datek Wireless AS uwe at datek.no http://datek.no/ From noreply at rubyforge.org Sat Jun 4 16:34:54 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 4 Jun 2011 16:34:54 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29253 ] Gem plugins + gem install -i causes activation errors Message-ID: <20110604203454.87426185836C@rubyforge.org> Bugs item #29253, was opened at 2011-06-04 13:34 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29253&group_id=126 Category: `gem install` command Group: v1.8.x Status: Open Resolution: None Priority: 3 Submitted By: Eric Hodel (drbrain) Assigned to: Nobody (None) Summary: Gem plugins + gem install -i causes activation errors Initial Comment: Steps to reproduce: gem install rubygems-test (has a rake dependency) gem install rake -v 0.8.7 gem install rake gem install -i /tmp/gems rake Expected results: rake installed in /tmp/gems Actual results: ./lib/rubygems/dependency.rb:252:in `to_specs': Could not find rake (>= 0.8.7) amongst [] (Gem::LoadError) from ./lib/rubygems/specification.rb:760:in `find_in_unresolved' from ./lib/rubygems/specification.rb:760:in `map' from ./lib/rubygems/specification.rb:760:in `find_in_unresolved' from ./lib/rubygems/custom_require.rb:43:in `require' from ./lib/rubygems/remote_fetcher.rb:63:in `initialize' from ./lib/rubygems/remote_fetcher.rb:48:in `new' from ./lib/rubygems/remote_fetcher.rb:48:in `fetcher' from ./lib/rubygems/spec_fetcher.rb:66:in `initialize' from ./lib/rubygems/spec_fetcher.rb:43:in `new' from ./lib/rubygems/spec_fetcher.rb:43:in `fetcher' from ./lib/rubygems/dependency_installer.rb:129:in `find_gems_with_sources' from ./lib/rubygems/dependency_installer.rb:269:in `find_spec_by_name_and_version' from ./lib/rubygems/dependency_installer.rb:300:in `install' from ./lib/rubygems/commands/install_command.rb:124:in `execute' from ./lib/rubygems/commands/install_command.rb:118:in `each' from ./lib/rubygems/commands/install_command.rb:118:in `execute' from ./lib/rubygems/command.rb:278:in `invoke' from ./lib/rubygems/command_manager.rb:161:in `process_args' from ./lib/rubygems/command_manager.rb:120:in `run' from ./lib/rubygems/gem_runner.rb:64:in `run' from /usr/bin/gem:21 `gem install -i path` changes the source directory for Gem::Specification so no gems are available. This works with RubyGems 1.7.2 and older, probably due to separate Gem::SourceIndexes for installation of gems and for loading gems. A workaround is to uninstall rubygems-test or uninstall the old version of rake. A possible fix could be to force-resolve dependencies when changing Gem::Specification's source directories ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29253&group_id=126 From luislavena at gmail.com Sat Jun 4 18:18:22 2011 From: luislavena at gmail.com (Luis Lavena) Date: Sat, 4 Jun 2011 18:18:22 -0400 Subject: [Rubygems-developers] Releasing gems for ruboto (JRuby on Android) In-Reply-To: <0B30AAB5-02DD-41D3-8F51-92154E519A96@datek.no> References: <3D1B361D-C145-4F2D-81C3-401FE973A752@datek.no> <16B69018B2894997A0344867B26E3044@gmail.com> <56C1C8E2-E846-4354-BF89-69DCC631B180@datek.no> <63E1BD9318F6470E9B4940C87E775361@gmail.com> <87CA885C-6527-4626-94A0-7AEDF075A5B9@segment7.net> <0B30AAB5-02DD-41D3-8F51-92154E519A96@datek.no> Message-ID: On Sat, Jun 4, 2011 at 4:27 PM, Uwe Kubosch wrote: > Ruboto has no command line for running the gem command. ?What library call does "gem env" result in? > There was no IRB for Ruboto? if so, then: require "rubygems" puts Gem::Platform.local Should display the one that matches you environment. Also, try: puts RUBY_PLATFORM puts RbConfig::CONFIG["host_os"] -- 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 uwe at datek.no Sun Jun 5 05:33:14 2011 From: uwe at datek.no (Uwe Kubosch) Date: Sun, 5 Jun 2011 09:33:14 +0000 Subject: [Rubygems-developers] Releasing gems for ruboto (JRuby on Android) In-Reply-To: References: <3D1B361D-C145-4F2D-81C3-401FE973A752@datek.no> <16B69018B2894997A0344867B26E3044@gmail.com> <56C1C8E2-E846-4354-BF89-69DCC631B180@datek.no> <63E1BD9318F6470E9B4940C87E775361@gmail.com> <87CA885C-6527-4626-94A0-7AEDF075A5B9@segment7.net> <0B30AAB5-02DD-41D3-8F51-92154E519A96@datek.no> Message-ID: <04C80F2D-54E2-4D7A-A210-0CF2DFFE115F@datek.no> On 2011-06-05, at 00:18, Luis Lavena wrote: > On Sat, Jun 4, 2011 at 4:27 PM, Uwe Kubosch wrote: >> Ruboto has no command line for running the gem command. What library call does "gem env" result in? > > There was no IRB for Ruboto? if so, then: Well, there is an IRB: the ruboto-irb app, but it takes Ruby code directly. We have no shell command line "gem" command. > require "rubygems" > puts Gem::Platform.local > > Should display the one that matches you environment. > Also, try: > > puts RUBY_PLATFORM > puts RbConfig::CONFIG["host_os"] Thanks, I will try this. -- Uwe Kubosch Systems Developer Datek Wireless AS uwe at datek.no http://datek.no/ From transfire at gmail.com Mon Jun 6 11:54:48 2011 From: transfire at gmail.com (Trans) Date: Mon, 6 Jun 2011 08:54:48 -0700 (PDT) Subject: [Rubygems-developers] Is #require_paths required? Message-ID: <1070bf29-4b61-48e1-8788-6b641fadbe4d@18g2000prd.googlegroups.com> I'm wondering if a gems `require_path` field is really necessary. To what extent is require_paths used by others? I know I use it one of my projects, and for a long time I thought I could not do without it, but now I think I see a reasonable alternative. So is it possible... Could we eliminate this field and standardize on the convention of a project's 'lib/' directory? Doing so would trivialize the relationship between $LOAD_PATH and the location of gems and grant us the usual benefits of convention over configuration. Does anyone have a scenario necessitates configurable require_paths? Or at least makes it extremely awkward to do without it? From evan at fallingsnow.net Mon Jun 6 12:20:36 2011 From: evan at fallingsnow.net (Evan Phoenix) Date: Mon, 6 Jun 2011 09:20:36 -0700 Subject: [Rubygems-developers] Is #require_paths required? In-Reply-To: <1070bf29-4b61-48e1-8788-6b641fadbe4d@18g2000prd.googlegroups.com> References: <1070bf29-4b61-48e1-8788-6b641fadbe4d@18g2000prd.googlegroups.com> Message-ID: See below. -- Evan Phoenix // evan at fallingsnow.net On Monday, June 6, 2011 at 8:54 AM, Trans wrote: > I'm wondering if a gems `require_path` field is really necessary. To > what extent is require_paths used by others? I know I use it one of my > projects, and for a long time I thought I could not do without it, but > now I think I see a reasonable alternative. > > So is it possible... Could we eliminate this field and standardize on > the convention of a project's 'lib/' directory? Doing so would > trivialize the relationship between $LOAD_PATH and the location of > gems and grant us the usual benefits of convention over > configuration. No, there are gems that specify multiple values for this for extensions and embedded libraries. There is no reason to lose configurability of this. That being said, require_paths defaults to ["lib"] so there is already the expected convention baked in. > > Does anyone have a scenario necessitates configurable require_paths? > Or at least makes it extremely awkward to do without it? > _______________________________________________ > Rubygems-developers mailing list > http://rubyforge.org/projects/rubygems > Rubygems-developers at rubyforge.org (mailto:Rubygems-developers at rubyforge.org) > http://rubyforge.org/mailman/listinfo/rubygems-developers From noreply at rubyforge.org Mon Jun 6 16:27:54 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 6 Jun 2011 16:27:54 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29257 ] Massively Duplicated Deprecation Warnings Message-ID: <20110606202755.2FC6A1858387@rubyforge.org> Bugs item #29257, was opened at 2011-06-06 16:27 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29257&group_id=126 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Scott Tadman (tadman) Assigned to: Nobody (None) Summary: Massively Duplicated Deprecation Warnings Initial Comment: I've added a pull request that tries to address some of the issues bundler has with deprecated functions: https://github.com/rubygems/rubygems/pull/70 This simply tracks which deprecations have been fired and doesn't trigger warnings for the same source line + method combination. The 1.8.5 version will report on deprecations an infinite number of times, something that nearly happens when some things are exercised inside a loop. Gem::SourceIndex#add_specs calls Gem::SourceIndex#add_spec many, many times, and both methods are deprecated. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29257&group_id=126 From noreply at rubyforge.org Mon Jun 6 19:10:03 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 6 Jun 2011 19:10:03 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29258 ] GEM_HOME=xxx gem install rake installs doco wrong Message-ID: <20110606231003.7A7CE185838E@rubyforge.org> Bugs item #29258, was opened at 2011-06-06 16:10 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29258&group_id=126 Category: `gem install` command Group: None Status: Open Resolution: None Priority: 3 Submitted By: Ryan Davis (zenspider) Assigned to: Eric Hodel (drbrain) Summary: GEM_HOME=xxx gem install rake installs doco wrong Initial Comment: % l xxx/gems/rake-0.8.7/xxx/doc/rake-0.8.7/ total 0 0 rdoc/ 0 ri/ ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29258&group_id=126 From noreply at rubyforge.org Tue Jun 7 06:07:17 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 7 Jun 2011 06:07:17 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29259 ] IO#tty? is not broken on Windows (MRI trunk) Message-ID: <20110607100717.16CE618583C7@rubyforge.org> Bugs item #29259, was opened at 2011-06-07 19:07 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29259&group_id=126 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Usaku Nakamura (usa) Assigned to: Nobody (None) Summary: IO#tty? is not broken on Windows (MRI trunk) Initial Comment: see r31952 of MRI. RubyGems should check RUBY_VERSION >= "1.9.3", I think. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29259&group_id=126 From noreply at rubyforge.org Tue Jun 7 10:10:08 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 7 Jun 2011 10:10:08 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29259 ] IO#tty? is not broken on Windows (MRI trunk) Message-ID: <20110607141008.63D333C8091@rubyforge.org> Bugs item #29259, was opened at 2011-06-07 07:07 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29259&group_id=126 >Category: `gem` commands (other) Group: None Status: Open >Resolution: Accepted Priority: 3 Submitted By: Usaku Nakamura (usa) >Assigned to: Luis Lavena (luislavena) Summary: IO#tty? is not broken on Windows (MRI trunk) Initial Comment: see r31952 of MRI. RubyGems should check RUBY_VERSION >= "1.9.3", I think. ---------------------------------------------------------------------- >Comment By: Luis Lavena (luislavena) Date: 2011-06-07 11:10 Message: Thank you Usa, will take a look and improve the code accordingly. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29259&group_id=126 From transfire at gmail.com Tue Jun 7 10:43:42 2011 From: transfire at gmail.com (Trans) Date: Tue, 7 Jun 2011 07:43:42 -0700 (PDT) Subject: [Rubygems-developers] Is #require_paths required? In-Reply-To: References: <1070bf29-4b61-48e1-8788-6b641fadbe4d@18g2000prd.googlegroups.com> Message-ID: <71b3f7a5-7a3d-4cfd-8707-af6d9f64ec17@z37g2000yqb.googlegroups.com> On Jun 6, 12:20?pm, Evan Phoenix wrote: > No, there are gems that specify multiple values for this for extensions and embedded libraries. There is no reason to lose configurability of this. Sure. I do so myself in one of my gems. But even if RubyGems would never change this because of backward compatibility, I'm asking a more philosophical question: could it work? I curious about cases were having multiple require paths has proven essential --where it just wouldn't be possible, or at least way too painful, without it. From drbrain at segment7.net Tue Jun 7 19:19:34 2011 From: drbrain at segment7.net (Eric Hodel) Date: Tue, 7 Jun 2011 16:19:34 -0700 Subject: [Rubygems-developers] Proposal for signing gems In-Reply-To: <4DE9A38B.2070503@grant-olson.net> References: <4DDEC026.7020207@grant-olson.net> <4DDED563.9080201@grant-olson.net> <9169DB74B10149F8A69DF991B7FABB1A@gmail.com> <4DDEEFC3.9050608@grant-olson.net> <6C54E1A6-65B0-4D52-A86E-E3C7F54949FF@segment7.net> <4DE9A38B.2070503@grant-olson.net> Message-ID: On Jun 3, 2011, at 8:16 PM, Grant Olson wrote: > On 6/3/2011 9:43 PM, Eric Hodel wrote: >> On May 26, 2011, at 5:26 PM, Grant Olson wrote: >> >>> 3) Is there interest in a simulated CA at a site like rubygems, as >>> described in the original post? >> >> Yes >> >> We could do something lazier too, IIRC `gem push` uses SSL to upload the gem, so rubygems.org could simply sign any gems with its own cert. No need for a CA or any of that stuff. (This proposal is overly simplistic currently). > > Do you mean your proposal or mine is simplistic? My proposal is overly simplistic due to all your comments below. (Perhaps you also suggested this but I skimmed it to quickly.) > It actually would be nice if rubygems signed the gem on push, if it > somehow verified the gem's authenticity when it was uploaded, above and > beyond the username/password check. There could be two different certs rubygems.org signs with, one for "enhanced" verification and one for only username/password verification. > From my perspective, that would still introduce some problems: > > Does rubygems.org deliver the certificate through a new remote API call, > or does it embed the sig in the uploaded gem? Either API change seems > problematic, and would require integration with rubygems (the gem) as > well. Signing a user's certificate could happen without modifiying the > core rubygems.org distribution system as it exists now. The easy way is to not use user certificates at all and just create a rubygems.org key for signing gems. The key's certificate would ship with RubyGems and any uploaded gem that didn't have a signature would be repackaged with a signature from the RubyGems key. > Anyway, I did create a gem called rubygems-openpgp that allows you to > sign and verify gems. I'm planning to add functionality to make signing > and building a single command. > > I'd like to make verifying and installing a single command, but it > doesn't look like there will be an easy way for me to hook into the > system between the fetch and install phases. It also looks problematic > to hook into any gem dependencies that automatically get downloaded, so > that they are verified as well. There are three hooks, pre_install, post_build and post_install. pre_install and post_build are both able to cancel an install by returning false. There's also a post_installs hook in master. Gems get installed in reverse dependency order, so you should be able to keep state in a separate class across installs to ensure everything is verified. From noreply at rubyforge.org Tue Jun 7 19:50:04 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 7 Jun 2011 19:50:04 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-14943 ] rubygems should use the same arch specific subdirs in lib for the native extensions as ruby Message-ID: <20110607235005.50D431D780FA@rubyforge.org> Bugs item #14943, was opened at 2007-10-22 03:57 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=14943&group_id=126 Category: RubyGems installer (setup.rb) Group: v0.9.5 Status: Open Resolution: None Priority: 1 Submitted By: Marcus Rueckert (darix) Assigned to: Eric Hodel (drbrain) Summary: rubygems should use the same arch specific subdirs in lib for the native extensions as ruby Initial Comment: quoting my my mail to ruby-core [1] [[[ there is another feature that gem doesnt handle nicely atm: with the standard ruby directory layout you can share the tree via nfs for multiple architectures as the native extensions are in an arch specific path. within an installed gem they are directly inside the "lib" subdir. i wonder if gem should use the arch specific subdirs below its "lib" subdir aswell. ]]] Eric asked me in a follow up to open a ticket here. :) Looking forward to the fix :) [1] http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/12724 ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-06-07 16:50 Message: Hi! Believe it or not, we're moving to github's issue tracker! The pressure to move has been loud and clear, but for the longest time it didn't support the way we worked. Now that it has freeform labels it can support our workflow adequately. There is just one problem: Your bug is here and we don't want to lose you! What we'd like you to do is fairly painless and should only take a few minutes: Please file the _exact_ same ticket on github and provide a link back to this crufty old ticket so we can refer to any previous discussion that occurred. Once the new ticket is made, put a forwarding link to it here and close this ticket out. In a couple weeks, we'll track down the old tickets that are still open and decide what to do with them. We could have done this fairly automatically, but we really want you to do it so you're attached to the ticket and we can still communicate with you and keep a record of it. https://github.com/rubygems/rubygems/issues Thanks, The RubyGems Team ---------------------------------------------------------------------- Comment By: James Tucker (raggi) Date: 2010-11-26 15:25 Message: VERSION should include prefix, suffix and full version. RubyCores idea that the contents of 1.9.1 are compatible with 1.9.x is a completely invalid assumption. I spoke to Matz about this at RubyConf. He suggested we speak to nobu. ---------------------------------------------------------------------- Comment By: Marcus Rueckert (darix) Date: 2010-11-25 11:59 Message: would be an option. but then you still need 2 search paths: 1. for pure ruby gems 2. one for gems with native portions. i just want consistent behavior, especially now that rubygems is in the core. although the $(Gem.dir)/gems/foo-1.0/lib/ method had the advantage for me that i could share the pure ruby stuff between all archs in my packages. but the other way would work for me aswell. ---------------------------------------------------------------------- Comment By: Luis Lavena (luislavena) Date: 2010-11-25 10:49 Message: Hello Marcus, There has been several conversations about the pollution of LOAD_PATH and a proposal of solution by Eric Hodel at ruby-core: http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/33206 I think making RubyGems add another PATH inside the same gem will be a problem. Instead, what if the default path where gems are installed contains the platform information? So Gem.dir and Gem.path uses ~/.gem/ENGINE/VERSION/PLATFORM Where ENGINE is ruby/jruby VERSION is 1.8 or 1.9.1 and PLATFORM is the one computed by Gem::Platform.local That will not solve the coexistence of the same codebase for two different platforms, but at least will avoid having another performance discussion at Ruby-Core Thoughts? ---------------------------------------------------------------------- Comment By: Marcus Rueckert (darix) Date: 2010-11-25 10:32 Message: 1. i think this ticket is still very valid. 2. i didnt mean that gems should be able to describe native libraries. while it would be nice it is not in the scope of this bug, so it should mostlikely be tracked in a different bug. If you open it, please CC me. I am sure i can give some tips and tricks how we solve it in the linux packaging world to achieve better cross distro support. ---------------------------------------------------------------------- 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: Hongli Lai (hongli) Date: 2010-01-20 14:37 Message: My experience with package management (Dev-C++, Autopackage, Phusion Passenger) so far is that dependency rules, especially for cross-platform software, can get very complex. I'm not sure whether it's at all possible to cover all cases without a turing-complete dependency specification language. Autopackage's dependency checking mechanism is turing-complete (shell scripts) and it works wonderfully well, though few people understand it because it's so powerful. But maybe it's possible to have a "good enough" system that works for most people, and let developers who need more power write their own thing, kinda like what we did for Phusion Passenger by splitting native dependency checking to passenger-install-*-module. For DebGem we didn't try to make RubyGems support native dependencies. We just manually maintained a per-gem native dependency list. I agree with not bothering with C++ compatibility. Most native extensions are written in C anyways. Developers can always write their own thing to handle this. For example the next version of Phusion Passenger will no longer specify extconf.rb in the gem spec; instead it will automatically compile the native extension when it's require()'ed into an Ruby version-, OS- and architecture-specific subdirectory under $HOME. As for Rubists being pitiful at dependency management: most Rubyists are on OS X which has no proper dependency management, so most people are not only unfamiliar with native dependency management but also wouldn't benefit from it. :) If RubyGems is to support native dependencies it should make it extremely easy for gem writers to specify them correctly. ---------------------------------------------------------------------- Comment By: James Tucker (raggi) Date: 2010-01-20 10:33 Message: I mean, whilst GCC versions might be ok for C++, what about say, a lua plugin or a php plugin, etc, etc. Tracking external dependencies and binary level compatibility becomes a nightmare with more VMs / runtimes, combined too with platforms, heh. Maybe, if we could pull in a more advanced extconf, that allowed arbitrary addition of dependency information, by reasonably formed keys, maybe such as: dependencies << [:debian, :package, :gcc, gcc_version] dependencies << [:debian, :package, :lua, lua_version] etc Then compute that based on some hash of the total dependency set (merged with rubys). So then you have a ruby dependency hash, from rbconfig (plus expanded info), and a gem dependency hash from install-time expansion data. I've actually missed something here, which is to tell the dependencies list how to check if those dependencies are still available... Need to store some code for that really, so eval strings (nominally probably calls to Kernel#`)... ---------------------------------------------------------------------- Comment By: James Tucker (raggi) Date: 2010-01-20 10:28 Message: Hongli Lai - agreed completely. A hash of some larger set of attributes may be most appropriate. As far as dependencies like C++ are concerned, there's little we can do to be complete in that area. I try to encourage a move toward proper dependency management, but rubyists are extremely pitiful at this traditionally. ---------------------------------------------------------------------- Comment By: James Tucker (raggi) Date: 2010-01-20 10:26 Message: I support the idea of putting a gem in an arch specific subdir. I am strongly against this subdir being inside the gems installed path. 1. some platform specific gems pack different *ruby* code in their gemfiles for specific archs 2. some gems do not use the commonly accepted paths, or have multiple lib paths, i wouldn't want selection of the path to become arbitrary ---------------------------------------------------------------------- Comment By: Hongli Lai (hongli) Date: 2010-01-20 08:27 Message: I support this change. This would make it possible for multiple Ruby interpreters, possibly on multiple machines with different platforms, to share the same gem directory. However I don't think Gem::Platform in its current form is adequate. While Gem::Platform is a good enough description of the platform, it isn't a good enough description of Ruby extension binary compatibility, which is what matters more. A few examples: - OS X Snow Leopard broke the ABI by switching to x86_64 by default, but uname and therefore RUBY_PLATFORM still report i386 as platform. - Ruby breaks API compatibility even between teeny releases, e.g. RSTRING_PTR vs RSTRING(x)->ptr. The former didn't exist until 1.8.6. On 1.8.7 and later it became required so that the latter doesn't work anymore. It doesn't look like the ABI changes but the Ruby core team doesn't seem to make any ABI guarantees. The switch from 1.8 to 1.9 most definitely breaks some ABI though. For Phusion Passenger we use the following code to identify Ruby extension binary compatibility: http://pastie.org/786648 But even this doesn't tell us the entire story. For example it doesn't include the C++ ABI version, which can be a problem for Ruby extensions written in C++ like EventMachine. GCC breaks the C++ ABI regularly, sometimes even multiple times within the same minor release. For example GCC 3.1 broke the C++ ABI about 3 times if I recall correctly. ---------------------------------------------------------------------- Comment By: Daniel Berger (djberg96) Date: 2009-02-01 20:56 Message: Luis, Right, modification to the extension builder would be required as far as I know. Dan ---------------------------------------------------------------------- Comment By: Luis Lavena (luislavena) Date: 2009-01-31 05:03 Message: Sorry not to properly introduce my question. Let's say I build a gem with VC6 (i386-mswin32), the gem platform is x86-mswin32-60 This means, my lib folder will be like this: lib/my_lib.rb lib/x86-mswin32-60/my_ext.so my_lib.rb contains this: require 'my_ext' now, I'm in a IRB session: require 'rubygems' require 'my_lib' It is supposed to work out. But what about this: require 'rubygems' require 'my_ext' Right now, since lib is added to LOAD_PATH on gem activation, there is no problem with that. With the change, it indicates that: If a gem contains a platform folder for libdir and the platform matches the current one, it should append that folder into LOAD_PATH. That is the correct assumption? I believe changes to Extension Builders bundled in rubygems will be required. ---------------------------------------------------------------------- Comment By: Daniel Berger (djberg96) Date: 2009-01-27 09:52 Message: Luis, I'm not sure what you mean by "require of the extension directly". Can you explain? Dan ---------------------------------------------------------------------- Comment By: Luis Lavena (luislavena) Date: 2009-01-27 09:01 Message: So this will mean "lib/#{Gem::Platform}" will be added to the $LOAD_PATH if exist, correct? What happens when users doing the require of the extension directly? it triggers the activation mechanism? I kind of like this, but maybe I'm missing a drawback that will against us in the long run? ---------------------------------------------------------------------- Comment By: Daniel Berger (djberg96) Date: 2009-01-26 12:24 Message: For example, if you install a C extension gem called 'foo' on Windows you want it to install as: C:/ruby/lib/ruby/gems/1.8/gems/foo/lib/i386-msvcr80/foo.so And Rubygems should add this sitearch directory to its search path? Is that about the sum of it? Regards, Dan ---------------------------------------------------------------------- Comment By: 7rans (transami) Date: 2007-11-06 02:27 Message: After some trial and error with extensions, I m starting to agree with this. It's more flexible. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=14943&group_id=126 From noreply at rubyforge.org Tue Jun 7 19:50:05 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 7 Jun 2011 19:50:05 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-28414 ] RubyGems 1.3.7 default gem directory is wrong when used with ruby 1.9.1 with --program-suffix=1.9 Message-ID: <20110607235005.72DAA185837F@rubyforge.org> Bugs item #28414, was opened at 2010-07-22 05:44 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28414&group_id=126 Category: `gem` commands (other) Group: v1.3.x Status: Open Resolution: None Priority: 3 Submitted By: Svetoslav Agafonkin (svetlyo) Assigned to: Eric Hodel (drbrain) Summary: RubyGems 1.3.7 default gem directory is wrong when used with ruby 1.9.1 with --program-suffix=1.9 Initial Comment: RubyGems 1.3.7 default gem directory is wrong when used with ruby 1.9.1 with --program-suffix=1.9. Gem.default_dir generates "/opt/local/lib/ruby/gems/1.9.1/" instead of "/opt/local/lib/ruby1.9/gems/1.9.1/". The change was introduced in lib/rubygems/defaults.rb in http://github.com/rubygems/rubygems/commit/0495c7c0dd9878f9a7a74f5133d7892d28d01812 - a big import from the ruby trunk, right after 1.3.6 was released. The original change comes from this commit: http://redmine.ruby-lang.org/repositories/diff/ruby-19?rev=26048 --------------------- Mac OS X 10.5.8 ruby 1.9.1_429 (from Macports) rubgygems 1.3.7 $ gem1.9 env RubyGems Environment: - RUBYGEMS VERSION: 1.3.7 - RUBY VERSION: 1.9.1 (2010-07-02 patchlevel 429) [i386-darwin9] - INSTALLATION DIRECTORY: /opt/local/lib/ruby/gems/1.9.1 - RUBY EXECUTABLE: /opt/local/bin/ruby1.9 - EXECUTABLE DIRECTORY: /opt/local/bin - RUBYGEMS PLATFORMS: - ruby - x86-darwin-9 - GEM PATHS: - /opt/local/lib/ruby/gems/1.9.1 - /Users/fro/.gem/ruby/1.9.1 - GEM CONFIGURATION: - :update_sources => true - :verbose => true - :benchmark => false - :backtrace => false - :bulk_threshold => 1000 - REMOTE SOURCES: - http://rubygems.org/ ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-06-07 16:50 Message: Hi! Believe it or not, we're moving to github's issue tracker! The pressure to move has been loud and clear, but for the longest time it didn't support the way we worked. Now that it has freeform labels it can support our workflow adequately. There is just one problem: Your bug is here and we don't want to lose you! What we'd like you to do is fairly painless and should only take a few minutes: Please file the _exact_ same ticket on github and provide a link back to this crufty old ticket so we can refer to any previous discussion that occurred. Once the new ticket is made, put a forwarding link to it here and close this ticket out. In a couple weeks, we'll track down the old tickets that are still open and decide what to do with them. We could have done this fairly automatically, but we really want you to do it so you're attached to the ticket and we can still communicate with you and keep a record of it. https://github.com/rubygems/rubygems/issues Thanks, The RubyGems Team ---------------------------------------------------------------------- Comment By: James Tucker (raggi) Date: 2010-11-13 08:20 Message: This is also related to a ruby bug that I need to submit. Feel free to assign to me after the we decide what to do with the suffix. ---------------------------------------------------------------------- Comment By: John Barnette (jbarnette) Date: 2010-11-13 05:44 Message: Eric, what do you think? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28414&group_id=126 From noreply at rubyforge.org Tue Jun 7 19:50:05 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 7 Jun 2011 19:50:05 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-28286 ] Removal of wrappers should occur *after* successful uninstallation Message-ID: <20110607235005.CAF173C807E@rubyforge.org> Bugs item #28286, was opened at 2010-06-08 21:11 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28286&group_id=126 Category: None Group: None Status: Open Resolution: Accepted Priority: 3 Submitted By: Sakuro OZAWA (sakuro) Assigned to: Ryan Davis (zenspider) Summary: Removal of wrappers should occur *after* successful uninstallation Initial Comment: When one terminates uninstallation of a gem, he/she would expect wrapper scripts remain. $ ruby --version ruby 1.9.3dev (2010-06-08 trunk 28202) [i386-darwin9.8.0] $ gem --version 1.3.7 $ gem uninstall nokogiri Remove executables: nokogiri in addition to the gem? [Yn] y Removing nokogiri You have requested to uninstall the gem: nokogiri-1.4.2 cucumber-0.8.0 depends on [nokogiri (>= 1.4.2)] mime-types-1.16 depends on [nokogiri (~> 1.2)] webrat-0.7.1 depends on [nokogiri (>= 1.2.0)] If you remove this gems, one or more dependencies will not be met. Continue with Uninstall? [Yn] n ERROR: While executing gem ... (Gem::DependencyRemovalException) Uninstallation aborted due to dependent gem(s) $ which nokogiri nokogiri not found ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-06-07 16:50 Message: Hi! Believe it or not, we're moving to github's issue tracker! The pressure to move has been loud and clear, but for the longest time it didn't support the way we worked. Now that it has freeform labels it can support our workflow adequately. There is just one problem: Your bug is here and we don't want to lose you! What we'd like you to do is fairly painless and should only take a few minutes: Please file the _exact_ same ticket on github and provide a link back to this crufty old ticket so we can refer to any previous discussion that occurred. Once the new ticket is made, put a forwarding link to it here and close this ticket out. In a couple weeks, we'll track down the old tickets that are still open and decide what to do with them. We could have done this fairly automatically, but we really want you to do it so you're attached to the ticket and we can still communicate with you and keep a record of it. https://github.com/rubygems/rubygems/issues Thanks, The RubyGems Team ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28286&group_id=126 From noreply at rubyforge.org Tue Jun 7 19:50:05 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 7 Jun 2011 19:50:05 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-27975 ] " gemspec is valid" has different meaning locally versus at submit time. Message-ID: <20110607235006.2B7473C809A@rubyforge.org> Bugs item #27975, was opened at 2010-03-16 09:49 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27975&group_id=126 Category: None Group: v1.3.x Status: Open Resolution: Accepted Priority: 3 Submitted By: Roger Pack (rogerdpack) Assigned to: Nick Quaranto (qrush) >Summary: "gemspec is valid" has different meaning locally versus at submit time. Initial Comment: Currently the gemspec validity check doesn't check for a valid url (if there is one), however gemcutter does, so there's some surprisingness when your gemspec "is valid" but then later "is no longer valid" when you go to submit it. suggestion: have the validity check check for valid url to avoid this surprisingness. Thanks. -r ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-06-07 16:50 Message: Hi! Believe it or not, we're moving to github's issue tracker! The pressure to move has been loud and clear, but for the longest time it didn't support the way we worked. Now that it has freeform labels it can support our workflow adequately. There is just one problem: Your bug is here and we don't want to lose you! What we'd like you to do is fairly painless and should only take a few minutes: Please file the _exact_ same ticket on github and provide a link back to this crufty old ticket so we can refer to any previous discussion that occurred. Once the new ticket is made, put a forwarding link to it here and close this ticket out. In a couple weeks, we'll track down the old tickets that are still open and decide what to do with them. We could have done this fairly automatically, but we really want you to do it so you're attached to the ticket and we can still communicate with you and keep a record of it. https://github.com/rubygems/rubygems/issues Thanks, The RubyGems Team ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27975&group_id=126 From noreply at rubyforge.org Tue Jun 7 19:50:06 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 7 Jun 2011 19:50:06 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-28844 ] rubygems plugins, 1.9 and circular requires Message-ID: <20110607235006.804EF3C809B@rubyforge.org> Bugs item #28844, was opened at 2011-01-09 17:24 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28844&group_id=126 Category: #gem and #require methods Group: v1.3.x Status: Open Resolution: None Priority: 3 Submitted By: Erik Hollensbe (erikh) Assigned to: Eric Hodel (drbrain) Summary: rubygems plugins, 1.9 and circular requires Initial Comment: I apologize in advance if this is confusing. I'm not entirely sure if this is gem_prelude's fault or rubygems's or even ruby proper's fault, but here goes: http://www.gem-testers.org/gems/rubygems-test/v/0.2.1/test_results/2 If you carefully examine the stack trace, you'll see that the rdoc plugin is being pulled in, then hanna is being pulled in. What happens in hanna is that rubygems is pulled in, ergo our problem. This is all done in from a rake process spawned by rubygems-test which uses open4 which in 1.9 uses threads, so threading may be a part of the issue here. This issue does not exhibit in 1.8, but it uses fork there. I was unable to test in RG 1.4 because of the obvious. I was able to fix this in rubygems-test 0.2.1 for the 'gem test' provider. The commit below is the fix. https://github.com/rubygems/rubygems-test/commit/72b0e136889fcd2509bb040de3fe9220c4b8bc13 You can see that I abuse autoload there to ensure that any rubygems dependencies (and YAML to be safe) are only loaded once. This is because of the above issue. These patches fix it but not for rdoc and (I presume) other plugins. What probably needs to happen is some beyond-the-call-of-duty $:/$" inspection before plugin load runs or to somehow load plugins with autoload (I don't think this is possible though). Obviously I'm deferring to your experience. Please feel free to tell me where to stick this bug report if it does not belong here, I'm just convinced after the discrete repros that it at least gets close to starting in rubygems. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-06-07 16:50 Message: Hi! Believe it or not, we're moving to github's issue tracker! The pressure to move has been loud and clear, but for the longest time it didn't support the way we worked. Now that it has freeform labels it can support our workflow adequately. There is just one problem: Your bug is here and we don't want to lose you! What we'd like you to do is fairly painless and should only take a few minutes: Please file the _exact_ same ticket on github and provide a link back to this crufty old ticket so we can refer to any previous discussion that occurred. Once the new ticket is made, put a forwarding link to it here and close this ticket out. In a couple weeks, we'll track down the old tickets that are still open and decide what to do with them. We could have done this fairly automatically, but we really want you to do it so you're attached to the ticket and we can still communicate with you and keep a record of it. https://github.com/rubygems/rubygems/issues Thanks, The RubyGems Team ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28844&group_id=126 From noreply at rubyforge.org Tue Jun 7 19:50:05 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 7 Jun 2011 19:50:05 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-28713 ] clean and remove should run in reverse topo sort Message-ID: <20110607235006.D49C43C809C@rubyforge.org> Bugs item #28713, was opened at 2010-11-12 13:46 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28713&group_id=126 Category: `gem` commands (other) Group: None Status: Open Resolution: Accepted Priority: 3 Submitted By: Ryan Davis (zenspider) Assigned to: Ryan Davis (zenspider) Summary: clean and remove should run in reverse topo sort Initial Comment: kiss my ass rubyforge. see summary. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-06-07 16:50 Message: Hi! Believe it or not, we're moving to github's issue tracker! The pressure to move has been loud and clear, but for the longest time it didn't support the way we worked. Now that it has freeform labels it can support our workflow adequately. There is just one problem: Your bug is here and we don't want to lose you! What we'd like you to do is fairly painless and should only take a few minutes: Please file the _exact_ same ticket on github and provide a link back to this crufty old ticket so we can refer to any previous discussion that occurred. Once the new ticket is made, put a forwarding link to it here and close this ticket out. In a couple weeks, we'll track down the old tickets that are still open and decide what to do with them. We could have done this fairly automatically, but we really want you to do it so you're attached to the ticket and we can still communicate with you and keep a record of it. https://github.com/rubygems/rubygems/issues Thanks, The RubyGems Team ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28713&group_id=126 From noreply at rubyforge.org Tue Jun 7 19:50:05 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 7 Jun 2011 19:50:05 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-28726 ] gem install --user-install as root adds cached .gem file outside of HOME Message-ID: <20110607235007.2B62A3C809D@rubyforge.org> Bugs item #28726, was opened at 2010-11-16 12:43 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28726&group_id=126 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Jeremy Evans (jeremyevans) Assigned to: Ryan Davis (zenspider) Summary: gem install --user-install as root adds cached .gem file outside of HOME Initial Comment: I think the problem is at https://github.com/rubygems/rubygems/blob/master/lib/rubygems/remote_fetcher.rb#L80 Basically, in RemoteFetcher#download, it's checking whether the install_dir (Gem.dir by default) is writable, and if so, it uses that dir. However, if the user is using the --user-install option, even if the user is root, it should not be writing outside of HOME/.gem. Basically, if the --user-install option is given, it should always download to HOME/.gem. This may require an API change. This affects building OpenBSD ports for some gems, since the --user-install option is used (in combination with a fake HOME). Usually, building is done as a regular user and is fine. However, if the builder is root, rubygems adds the .gem files to the /usr/local/lib/ruby directory when the gem is installed to HOME/.gem. Then when the package builder goes to install the package, the cached .gem file already exists and the package install fails. This isn't a critical bug, as it can be trivially worked around by specifying GEM_HOME=$HOME/.gem in the environment when using gem install --user-install (which the OpenBSD ports system now does). ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-06-07 16:50 Message: Hi! Believe it or not, we're moving to github's issue tracker! The pressure to move has been loud and clear, but for the longest time it didn't support the way we worked. Now that it has freeform labels it can support our workflow adequately. There is just one problem: Your bug is here and we don't want to lose you! What we'd like you to do is fairly painless and should only take a few minutes: Please file the _exact_ same ticket on github and provide a link back to this crufty old ticket so we can refer to any previous discussion that occurred. Once the new ticket is made, put a forwarding link to it here and close this ticket out. In a couple weeks, we'll track down the old tickets that are still open and decide what to do with them. We could have done this fairly automatically, but we really want you to do it so you're attached to the ticket and we can still communicate with you and keep a record of it. https://github.com/rubygems/rubygems/issues Thanks, The RubyGems Team ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28726&group_id=126 From noreply at rubyforge.org Tue Jun 7 19:50:05 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 7 Jun 2011 19:50:05 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-28742 ] Manual states gemrc is looked up in home directory only whereas /etc/gemrc is also consulted Message-ID: <20110607235007.7B2FC185837F@rubyforge.org> Bugs item #28742, was opened at 2010-11-22 09:02 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28742&group_id=126 Category: documentation Group: v1.3.x Status: Open Resolution: None Priority: 3 Submitted By: Rich Meyers (richmeyers) Assigned to: Eric Hodel (drbrain) Summary: Manual states gemrc is looked up in home directory only whereas /etc/gemrc is also consulted Initial Comment: Documentation here: http://docs.rubygems.org/read/chapter/11 states: gem looks for a configuration file .gemrc in your home directory, although you can specify another file on the command-line if you wish (with the ?config-file modifier). Only one configuration file will be processed: the rightmost one on the command-line, or the default $HOME/.gemrc, or none at all. In actuality, configuration may be taken from /etc/gemrc if it exists. RubyGems Environment: - RUBYGEMS VERSION: 1.3.7 - RUBY VERSION: 1.8.7 (2009-12-24 patchlevel 248) [amd64-freebsd8] - INSTALLATION DIRECTORY: /usr/local/lib/ruby/gems/1.8 - RUBY EXECUTABLE: /usr/local/bin/ruby18 - EXECUTABLE DIRECTORY: /usr/local/bin - RUBYGEMS PLATFORMS: - ruby - amd64-freebsd-8 - GEM PATHS: - /usr/local/lib/ruby/gems/1.8 - /home/rm/.gem/ruby/1.8 - GEM CONFIGURATION: - :update_sources => true - :verbose => true - :benchmark => false - :backtrace => false - :bulk_threshold => 1000 - REMOTE SOURCES: - http://gems.rubyforge.org ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-06-07 16:50 Message: Hi! Believe it or not, we're moving to github's issue tracker! The pressure to move has been loud and clear, but for the longest time it didn't support the way we worked. Now that it has freeform labels it can support our workflow adequately. There is just one problem: Your bug is here and we don't want to lose you! What we'd like you to do is fairly painless and should only take a few minutes: Please file the _exact_ same ticket on github and provide a link back to this crufty old ticket so we can refer to any previous discussion that occurred. Once the new ticket is made, put a forwarding link to it here and close this ticket out. In a couple weeks, we'll track down the old tickets that are still open and decide what to do with them. We could have done this fairly automatically, but we really want you to do it so you're attached to the ticket and we can still communicate with you and keep a record of it. https://github.com/rubygems/rubygems/issues Thanks, The RubyGems Team ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28742&group_id=126 From noreply at rubyforge.org Tue Jun 7 19:50:06 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 7 Jun 2011 19:50:06 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-28935 ] Failing rdoc generation doesnt fail the installation since 1.5 Message-ID: <20110607235007.AFFC33C809E@rubyforge.org> Bugs item #28935, was opened at 2011-02-17 11:16 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28935&group_id=126 Category: `gem install` command Group: None Status: Open Resolution: Accepted Priority: 3 Submitted By: Marcus Rueckert (darix) Assigned to: Eric Hodel (drbrain) Summary: Failing rdoc generation doesnt fail the installation since 1.5 Initial Comment: it seems gem install returns 0, even though the rdoc generation failed. in 1.3.7 it still returned the a non zero return code. as shown here http://bit.ly/f8vfi7 e.g. important part: [[[ 1 gem installed Installing ri documentation for ci_reporter-1.6.4... rdoc --ri --op /var/tmp/rubygem-ci_reporter-1.6.4-build/usr/lib64/ruby/gems/1.8/doc/ci_reporter-1.6.4/ri --main README.txt -SHN -f darkfish --quiet lib History.txt Manifest.txt README.txt LICENSE.txt --title ci_reporter-1.6.4 Documentation Installing RDoc documentation for ci_reporter-1.6.4... rdoc --op /var/tmp/rubygem-ci_reporter-1.6.4-build/usr/lib64/ruby/gems/1.8/doc/ci_reporter-1.6.4/rdoc --main README.txt -SHN -f darkfish --quiet lib History.txt Manifest.txt README.txt LICENSE.txt --title ci_reporter-1.6.4 Doc Invalid output formatter For help on options, try 'rdoc --help' ERROR: While generating documentation for ci_reporter-1.6.4 ... MESSAGE: exit ... RDOC args: --op /var/tmp/rubygem-ci_reporter-1.6.4-build/usr/lib64/ruby/gems/1.8/doc/ci_reporter-1.6.4/rdoc --main README.txt -SHN -f darkfish --quiet lib History.txt Manifest.txt README.txt LICENSE.txt --title ci_reporter-1.6.4 Documentation (continuing with the rest of the installation) ]]] the problem in the build was that the ruby version didnt ship the darkfish template, but the gemspec specifies 's.rdoc_options = ["--main", "README.txt", "-SHN", "-f", "darkfish"]'. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-06-07 16:50 Message: Hi! Believe it or not, we're moving to github's issue tracker! The pressure to move has been loud and clear, but for the longest time it didn't support the way we worked. Now that it has freeform labels it can support our workflow adequately. There is just one problem: Your bug is here and we don't want to lose you! What we'd like you to do is fairly painless and should only take a few minutes: Please file the _exact_ same ticket on github and provide a link back to this crufty old ticket so we can refer to any previous discussion that occurred. Once the new ticket is made, put a forwarding link to it here and close this ticket out. In a couple weeks, we'll track down the old tickets that are still open and decide what to do with them. We could have done this fairly automatically, but we really want you to do it so you're attached to the ticket and we can still communicate with you and keep a record of it. https://github.com/rubygems/rubygems/issues Thanks, The RubyGems Team ---------------------------------------------------------------------- Comment By: Eric Hodel (drbrain) Date: 2011-03-01 14:52 Message: I could not reproduce the behavior of --quiet suppressing the exit code with ci_reporter and RDoc 1.0.1, 2.3.0, 2.5.11 or trunk rdoc. I reverted the commit in RubyGems that add --quiet as it has no effect on the exit code. Reopened this bug. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-02-23 16:49 Message: DocManager was passing in --quiet which does a lot more than just "don't output stuff". I've removed that and forced the exit to be 1 if it borks. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28935&group_id=126 From noreply at rubyforge.org Tue Jun 7 19:50:06 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 7 Jun 2011 19:50:06 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-28889 ] gem rdoc --all --overwrite doesn't work Message-ID: <20110607235009.5A59B3C809A@rubyforge.org> Bugs item #28889, was opened at 2011-01-28 12:07 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28889&group_id=126 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: V?t Ondruch (voxik) Assigned to: Eric Hodel (drbrain) Summary: gem rdoc --all --overwrite doesn't work Initial Comment: C:\>gem rdoc --all --overwrite Installing ri documentation for bundler-1.0.9... Installing ri documentation for minitest-2.0.2... ERROR: While executing gem ... (Errno::ENOENT) No such file or directory - C:/Users/vita/.pik/rubies/Ruby-193-dev/lib/ruby/gems/1.9.1/gems/minitest-2.0.2 It is apparently one of the bundled gems, therefore the directory cannot be found. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-06-07 16:50 Message: Hi! Believe it or not, we're moving to github's issue tracker! The pressure to move has been loud and clear, but for the longest time it didn't support the way we worked. Now that it has freeform labels it can support our workflow adequately. There is just one problem: Your bug is here and we don't want to lose you! What we'd like you to do is fairly painless and should only take a few minutes: Please file the _exact_ same ticket on github and provide a link back to this crufty old ticket so we can refer to any previous discussion that occurred. Once the new ticket is made, put a forwarding link to it here and close this ticket out. In a couple weeks, we'll track down the old tickets that are still open and decide what to do with them. We could have done this fairly automatically, but we really want you to do it so you're attached to the ticket and we can still communicate with you and keep a record of it. https://github.com/rubygems/rubygems/issues Thanks, The RubyGems Team ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28889&group_id=126 From noreply at rubyforge.org Tue Jun 7 19:50:06 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 7 Jun 2011 19:50:06 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-28902 ] Specification#ruby_code should be more secure with arrays Message-ID: <20110607235009.321DA3C807E@rubyforge.org> Bugs item #28902, was opened at 2011-02-01 20:12 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28902&group_id=126 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Ryan Davis (zenspider) Assigned to: Ryan Davis (zenspider) Summary: Specification#ruby_code should be more secure with arrays Initial Comment: Either check that everything within is clean, or recurse on each member. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-06-07 16:50 Message: Hi! Believe it or not, we're moving to github's issue tracker! The pressure to move has been loud and clear, but for the longest time it didn't support the way we worked. Now that it has freeform labels it can support our workflow adequately. There is just one problem: Your bug is here and we don't want to lose you! What we'd like you to do is fairly painless and should only take a few minutes: Please file the _exact_ same ticket on github and provide a link back to this crufty old ticket so we can refer to any previous discussion that occurred. Once the new ticket is made, put a forwarding link to it here and close this ticket out. In a couple weeks, we'll track down the old tickets that are still open and decide what to do with them. We could have done this fairly automatically, but we really want you to do it so you're attached to the ticket and we can still communicate with you and keep a record of it. https://github.com/rubygems/rubygems/issues Thanks, The RubyGems Team ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28902&group_id=126 From noreply at rubyforge.org Tue Jun 7 19:50:07 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 7 Jun 2011 19:50:07 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29145 ] Dynamically generated GemSpec.files ends up empty Message-ID: <20110607235009.798DD3C809B@rubyforge.org> Bugs item #29145, was opened at 2011-04-23 04:36 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29145&group_id=126 Category: `gem install` command Group: None Status: Open Resolution: None Priority: 3 Submitted By: Lars Christensen (larsch) Assigned to: James Tucker (raggi) Summary: Dynamically generated GemSpec.files ends up empty Initial Comment: Prawn's gemspec: spec.files = Dir.glob("{examples,lib,spec,data}/**/**/*") + ["Rakefile", "prawn.gemspec"] With pristine 1.9.2-p180 on Windows (all good): C:\>gem --version 1.5.2 C:\>gem install prawn ... specifications/prawn-0.11.1.gemspec: s.files = ["examples/example_helper.rb"," examples/bounding_box/stretched_nesting.rb", "examples/bounding_box/bounding_boxes.rb", "examples/bounding_box/indentation.rb", ... ] With upgrades rubygems (s.files misses files): C:\>gem update --system ... C:\>gem --version 1.7.2 C:\>gem install prawn ... specifications/prawn-0.11.1.gemspec: s.files = ["HACKING", "README", "LICENSE", "COPYING"] All .rb files are missing in .files. Currently ocra (http://ocra.rubyforge.org/) uses .files to find the files that are included in a gem, and hence fails miserably when they are not actually listen in the .gemspec file. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-06-07 16:50 Message: Hi! Believe it or not, we're moving to github's issue tracker! The pressure to move has been loud and clear, but for the longest time it didn't support the way we worked. Now that it has freeform labels it can support our workflow adequately. There is just one problem: Your bug is here and we don't want to lose you! What we'd like you to do is fairly painless and should only take a few minutes: Please file the _exact_ same ticket on github and provide a link back to this crufty old ticket so we can refer to any previous discussion that occurred. Once the new ticket is made, put a forwarding link to it here and close this ticket out. In a couple weeks, we'll track down the old tickets that are still open and decide what to do with them. We could have done this fairly automatically, but we really want you to do it so you're attached to the ticket and we can still communicate with you and keep a record of it. https://github.com/rubygems/rubygems/issues Thanks, The RubyGems Team ---------------------------------------------------------------------- Comment By: Luis Lavena (luislavena) Date: 2011-05-23 17:47 Message: I've bring this topic to RubyGems devel list before: http://rubyforge.org/pipermail/rubygems-developers/2011-May/006539.html Like you I depend on that functionality. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29145&group_id=126 From noreply at rubyforge.org Tue Jun 7 19:50:07 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 7 Jun 2011 19:50:07 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29170 ] with multiple sources, if one is unavailable, nothing works at all Message-ID: <20110607235009.9458C3C809C@rubyforge.org> Bugs item #29170, was opened at 2011-05-05 20:40 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29170&group_id=126 Category: `gem install` command Group: None Status: Open Resolution: Accepted Priority: 3 Submitted By: Nick Klauer (klauern) Assigned to: Ryan Davis (zenspider) Summary: with multiple sources, if one is unavailable, nothing works at all Initial Comment: With the Amazon outage, one of the sources I had added outside of rubygems was down (http://rubygems.torquebox.org). For me, this wasn't a big issue, since it hosts only a few gems that I use and I don't need updated that often. However, when trying to install a gem or update gems, it would shut down entirely, not being able to find specs.4.8.gz for that one source. So in effect, `gem update` was borked because one source wasn't available, regardless of the status of all others. If possible, can this just display a warning or something saying that "can't search ${borked gem server source}, skipping this one" and still try to update, install, etc., from any and all other sources listed? ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-06-07 16:50 Message: Hi! Believe it or not, we're moving to github's issue tracker! The pressure to move has been loud and clear, but for the longest time it didn't support the way we worked. Now that it has freeform labels it can support our workflow adequately. There is just one problem: Your bug is here and we don't want to lose you! What we'd like you to do is fairly painless and should only take a few minutes: Please file the _exact_ same ticket on github and provide a link back to this crufty old ticket so we can refer to any previous discussion that occurred. Once the new ticket is made, put a forwarding link to it here and close this ticket out. In a couple weeks, we'll track down the old tickets that are still open and decide what to do with them. We could have done this fairly automatically, but we really want you to do it so you're attached to the ticket and we can still communicate with you and keep a record of it. https://github.com/rubygems/rubygems/issues Thanks, The RubyGems Team ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29170&group_id=126 From noreply at rubyforge.org Tue Jun 7 19:50:07 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 7 Jun 2011 19:50:07 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29173 ] cleanup should show me what other gems I have installed when determining whether to uninstall Message-ID: <20110607235009.C823A18583CC@rubyforge.org> Bugs item #29173, was opened at 2011-05-06 06:24 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29173&group_id=126 Category: `gem` commands (other) Group: None Status: Open Resolution: None Priority: 3 Submitted By: Nick Klauer (klauern) Assigned to: Ryan Davis (zenspider) Summary: cleanup should show me what other gems I have installed when determining whether to uninstall Initial Comment: When i do a `gem update` I often follow-up with `gem cleanup`. However, it's hard to tell whether to uninstall a gem when I see this: Attempting to uninstall warden-0.10.7 You have requested to uninstall the gem: warden-0.10.7 devise-1.1.2 depends on [warden (~> 0.10.7)] If you remove this gems, one or more dependencies will not be met. Continue with Uninstall? [Yn] I don't know if the newer version of warden is an entirely different version (1.0 or something) or compatible with the ~> requirement. Taken further, cleanup should know enough about the version requirement to save me the trouble of this anyway, especially if the requirement is =someversion, when you know that the gem authors don't want any other version. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-06-07 16:50 Message: Hi! Believe it or not, we're moving to github's issue tracker! The pressure to move has been loud and clear, but for the longest time it didn't support the way we worked. Now that it has freeform labels it can support our workflow adequately. There is just one problem: Your bug is here and we don't want to lose you! What we'd like you to do is fairly painless and should only take a few minutes: Please file the _exact_ same ticket on github and provide a link back to this crufty old ticket so we can refer to any previous discussion that occurred. Once the new ticket is made, put a forwarding link to it here and close this ticket out. In a couple weeks, we'll track down the old tickets that are still open and decide what to do with them. We could have done this fairly automatically, but we really want you to do it so you're attached to the ticket and we can still communicate with you and keep a record of it. https://github.com/rubygems/rubygems/issues Thanks, The RubyGems Team ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-05-06 15:40 Message: I'm not sure whether my reverse-topo-sort ticket would address this or not. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29173&group_id=126 From noreply at rubyforge.org Tue Jun 7 19:50:07 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 7 Jun 2011 19:50:07 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29116 ] Mega slowness in custom require Message-ID: <20110607235009.AB69118583AB@rubyforge.org> Bugs item #29116, was opened at 2011-04-05 11:01 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29116&group_id=126 Category: #gem and #require methods Group: None Status: Open Resolution: None Priority: 3 Submitted By: Sam Goldstein (samgoldstein) Assigned to: Ryan Davis (zenspider) Summary: Mega slowness in custom require Initial Comment: I recently upgraded to rubygems 1.6.5 and started experiencing a major slowdown loading the environment for a Rails 2.3 application. I traced the problem back to the Kernel.require (custom_require.rb) and Gem.loaded_path?. It seems that searching $LOADED_FEATURES repeatedly is inefficient and results in a 4x slowdown in my specific case. I've downgraded to rubygems 1.3.5 which doesn't suffer from this problem. This is a major hurdle to developing in ruby, as it takes me ~45 seconds to load the environment and run one test. Below is some console output demonstrating the problem. /www/aboutus/app_root [master] $ time rake environment (in /www/aboutus/app_root) real 0m11.407s user 0m8.787s sys 0m2.552s /www/aboutus/app_root [master] $ sudo gem update --system Updating RubyGems Updating rubygems-update Successfully installed rubygems-update-1.7.1 Updating RubyGems to 1.7.1 Installing RubyGems 1.7.1 RubyGems 1.7.1 installed === 1.7.1 / 2011-03-32 * 1 bug fix: * Fixed missing file in Manifest.txt. (Also a bug in hoe was fixed where `rake check_manifest` showing a diff would not exit with an error.) ------------------------------------------------------------------------------ RubyGems installed the following executables: /usr/local/bin/gem /www/aboutus/app_root [master] $ time rake environment (in /www/aboutus/app_root) NOTE: SourceIndex.new(hash) is deprecated; From /www/aboutus/app_root/config/../vendor/rails/railties/lib/rails/vendor_gem_source_index.rb:100:in `new'. real 0m46.707s user 0m41.200s sys 0m5.394s Thanks! ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-06-07 16:50 Message: Hi! Believe it or not, we're moving to github's issue tracker! The pressure to move has been loud and clear, but for the longest time it didn't support the way we worked. Now that it has freeform labels it can support our workflow adequately. There is just one problem: Your bug is here and we don't want to lose you! What we'd like you to do is fairly painless and should only take a few minutes: Please file the _exact_ same ticket on github and provide a link back to this crufty old ticket so we can refer to any previous discussion that occurred. Once the new ticket is made, put a forwarding link to it here and close this ticket out. In a couple weeks, we'll track down the old tickets that are still open and decide what to do with them. We could have done this fairly automatically, but we really want you to do it so you're attached to the ticket and we can still communicate with you and keep a record of it. https://github.com/rubygems/rubygems/issues Thanks, The RubyGems Team ---------------------------------------------------------------------- Comment By: Dan Peterson (dpiddy) Date: 2011-06-01 05:31 Message: Here's what my test case looks like with 1.5.2, 1.8.5 and master after Evan's change: # 1.5.2 eye help 1.26s user 0.26s system 99% cpu 1.526 total # 1.8.5 eye help 9.85s user 0.61s system 100% cpu 10.455 total # master eye help 5.44s user 0.51s system 100% cpu 5.947 total ---------------------------------------------------------------------- Comment By: Evan Phoenix (evan) Date: 2011-05-31 23:53 Message: I've moved the regexp creation outside the find block. Could someone who's seeing the issue report back how much of a difference it made? ---------------------------------------------------------------------- Comment By: Nick Rogers (tsp435cds) Date: 2011-05-30 14:47 Message: I am experiencing the same problem with my rails 2.3.11 application, recently upgraded from rubygems 1.3.7 to 1.7.2. Time to initialize rails is an abysmal average of 30s instead of 5s, and I use only a handful of gems. ~/rxg/console: rake gems (in /Users/nick/rxg/console) - [F] attr_encrypted - [F] eigenclass >= 1.1.1 - [F] encryptor >= 1.1.0 - [F] mocha >= 0.9.8 - [R] rake - [F] log4r - [F] netaddr - [F] ntp - [F] hoe >= 1.2.0 - [F] rubyforge >= 2.0.4 - [R] json_pure >= 1.1.7 - [R] rake >= 0.8.7 - [F] SystemTimer - [F] rack - [F] savon - [F] builder >= 2.1.2 - [F] crack >= 0.1.4 - [F] surpass I = Installed F = Frozen R = Framework (loaded before rails starts) ~/rxg/console: I concur that the problem is with custom_require, specifically Gem#loaded_path? and possibly elsewhere. Glancing at rubygems.rb, there are a number of careless instances of what should be loop invariant variables being re-computed within a loop. For example, the following change yielded a 50% performance increase to my rails app load time, however it was still not as good as under rubygems 1.3.7. *** rubygems-1.7.2-original/lib/rubygems.rb 2011-04-05 16:59:14.000000000 -0400 --- rubygems-1.7.2/lib/rubygems.rb 2011-05-30 17:20:56.000000000 -0400 *************** *** 1086,1093 **** def self.loaded_path? path # TODO: ruby needs a feature to let us query what's loaded in 1.8 and 1.9 $LOADED_FEATURES.find { |s| ! s =~ /(^|\/)#{Regexp.escape path}#{Regexp.union(*Gem.suffixes)}$/ } end --- 1086,1095 ---- def self.loaded_path? path # TODO: ruby needs a feature to let us query what's loaded in 1.8 and 1.9 + escaped_path = Regexp.escape(path) + union_suffixes = Regexp.union(*Gem.suffixes) $LOADED_FEATURES.find { |s| ! s =~ /(^|\/)#{escaped_path}#{union_suffixes}$/ } end ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-05-23 17:32 Message: More data, this time with a bit more cleanup and working against rails 2.3.12 (coming RSN) so that deprecations are cleaned up: repo=before-clean repo=after-clean number of gems: 280 number of gems: 175 1.3.7 real 0m2.113s real 0m1.901s user 0m1.762s user 0m1.582s sys 0m0.339s sys 0m0.314s 1.7.2 real 0m7.269s real 0m1.639s user 0m6.836s user 0m1.405s sys 0m0.417s sys 0m0.222s 1.8.2 real 0m7.947s real 0m1.920s user 0m7.488s user 0m1.680s sys 0m0.413s sys 0m0.228s Kinda scary how much those 105 gems affect stuff. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-05-23 16:47 Message: Much of this slowdown occurred as a result of us fixing complex gem dependency resolution bugs. Unfortunately, we're not in a good place to do too much to address this issue right now. I will point out that in both old (< 1.4) rubygems and newer, that the time is going to be proportional to the amount of gems installed. Keeping around a bunch of old stuff you're not using will only harm you in any version. I did get a repro using MOST of what Sam reported. I couldn't install some gems because I didn't have requisite libraries (eg I never use mysql, so it couldn't build) and some of his gems are not in the main gem repo. Of his 287 gems (WOW!) I was able to install 273 of them. Until I tried out a rails app, EVERY timing I tried to do wound up at least 25% faster in 1.7/1.8 over 1.3.7. Once we got to really complex graphs of activation (read: rails), I was able to get a repro where 1.7/1.8 was slower. I got the following times while loading a rails 2.3.4 config/environment.rb file: repo=xxx; before 'gem clean' number of gems: 273 1.3.7 real 0m1.492s user 0m1.230s sys 0m0.256s 1.7.2 real 0m3.533s user 0m3.281s sys 0m0.242s 1.8.2 real 0m3.998s user 0m3.731s sys 0m0.261s I copied that repo and ran gem clean on it (and reinstalled rails 2.3.4 because rails 3 wiped it out on cleanup!) and got the following MUCH better times: repo=yyy; after 'gem clean' number of gems: 183 1.3.7 real 0m1.288s user 0m1.054s sys 0m0.231s 1.7.2 real 0m1.106s user 0m0.932s sys 0m0.169s 1.8.2 real 0m1.365s user 0m1.181s sys 0m0.179s So... that's the workaround for now. I'll do what I can to profile and optimize, but I can't promise much for the next release, partially because we don't have enough test coverage on this aspect of rubygems. ---------------------------------------------------------------------- Comment By: Dan Peterson (dpiddy) Date: 2011-05-23 08:20 Message: This is still happening in 1.8.3. ---------------------------------------------------------------------- Comment By: Dan Peterson (dpiddy) Date: 2011-05-04 18:42 Message: I have seen this as well for something non-Rails. Using `rvm rubygems` I saw the slowness started with 1.6.0. Haven't had a chance to really dig into it more yet. ---------------------------------------------------------------------- Comment By: Sam Goldstein (samgoldstein) Date: 2011-04-05 11:07 Message: More info on gem dependencies and installed gems. $ rake gems (in /www/aboutus/compostus/compost) - [F] thrift_client ~> 0.4.3 - [I] thrift - [I] thrift = 0.2.0.4 - [F] simple_uuid = 0.1.1 - [F] cassandra = 0.8.2 - [F] thrift_client >= 0.4.0 - [I] thrift - [I] json - [R] rake - [F] simple_uuid >= 0.1.0 - [F] rack ~> 1.0.0 - [F] diff-lcs = 1.1.2 - [I] ffi ~> 0.6.0 - [R] rake >= 0.8.7 - [F] haml - [I] libxml-ruby - [I] hpricot >= 0.8.1 - [I] json - [I] mysql = 2.8.1 - [F] net-ssh - [F] ya2yaml = 0.26 - [F] ruby-openid = 2.1.6 - [F] mechanize = 1.0.0 - [I] nokogiri >= 1.2.1 - [I] nokogiri - [F] composite_primary_keys = 2.2.2 - [R] activerecord >= 2.2.0 - [F] aws-s3 = 0.6.2 - [F] xml-simple - [F] builder - [F] mime-types - [F] right_aws - [F] right_http_connection >= 1.2.4 - [F] fastercsv = 1.5.0 - [I] levenshtein - [F] newrelic_rpm = 2.13.4 - [F] after_commit ~> 1.0.7 - [R] activerecord - [F] less = 1.2.21 - [F] treetop >= 1.4.2 - [F] polyglot >= 0.3.1 - [F] mutter >= 0.4.2 - [F] treetop = 1.4.8 - [F] polyglot >= 0.3.1 - [F] mime-types = 1.16 - [I] curb = 0.7.8 I = Installed F = Frozen R = Framework (loaded before rails starts) $ gem list abstract (1.0.0) actionmailer (3.0.5, 3.0.3, 2.3.4, 2.2.2) actionpack (3.0.5, 3.0.3, 2.3.4, 2.2.2) activemodel (3.0.5, 3.0.3) activerecord (3.0.5, 3.0.3, 2.3.4, 2.2.2) activeresource (3.0.5, 3.0.3, 2.3.4, 2.2.2) activesupport (3.0.5, 3.0.3, 2.3.11, 2.3.8, 2.3.7, 2.3.5, 2.3.4, 2.2.2) acts_as_commentable (3.0.1, 2.0.2) addressable (2.2.4) after_commit (1.0.7, 1.0.5) amatch (0.2.3) amazon_sdb (0.6.7) amqp (0.6.0) ar-extensions (0.8.0) arel (2.0.9, 2.0.8) au_document_parser (0.5.3, 0.4.3, 0.4.2, 0.4.1, 0.4.0, 0.3.2, 0.3.1, 0.3.0, 0.2.4) autotest-growl (0.1.7) aws-s3 (0.6.2) babel (0.1.4) builder (2.1.2) bundler (1.0.10) capistrano (2.5.5) capybara (0.3.0) carmen (0.2.5) cassandra (0.7.2, 0.6) cgi_multipart_eof_fix (2.5.0) cheat (1.2.1) chronic (0.3.0, 0.2.3) clearance (0.10.3.2, 0.8.8, 0.8.3) compass (0.8.17) compass-960-plugin (0.9.11) composite_primary_keys (2.2.2) configuration (1.1.0) crack (0.1.4) cucumber (0.10.2, 0.6.3, 0.6.2) cucumber-rails (0.3.2, 0.2.4, 0.2.3) culerity (0.2.6) curb (0.7.8, 0.7.7.1, 0.7.1) daemons (1.0.10) database_cleaner (0.4.3) diesel (0.1.4) diff-lcs (1.1.2) differ (0.1.1) diffy (2.0.1) dirb (1.0.0, 0.1.1, 0.1.0) duration (0.1.0) erubis (2.6.6) eventmachine (0.12.10) factory_girl (1.2.3) fakefs (0.2.1) faker (0.3.1) faraday (0.5.7) fastercsv (1.5.0) fastthread (1.0.7) ffi (0.6.3, 0.5.4, 0.5.3) file-tail (1.0.4) fixjour (0.1.6) flexmock (0.8.6) gem_plugin (0.2.3) gemcutter (0.5.0) geminstaller (0.5.4) geokit (1.5.0) getopt-declare (1.28) gherkin (2.3.5) git (1.2.5) gltail (0.1.8) gravatar (1.0) grit (2.0.0, 1.1.1) haml (3.0.25, 3.0.13, 2.2.19, 2.2.9) heroku (1.9.8) highline (1.5.1) hoe (2.3.3) hpricot (0.8.1) httparty (0.5.0) i18n (0.5.0) icalendar (1.1.2, 1.1.0) jeweler (1.4.0) jm81-whois (0.5.0) json (1.4.6, 1.2.0, 1.1.6) json_pure (1.2.0) launchy (0.3.3) less (1.2.21) levenshtein (0.2.0) libxml-ruby (1.1.3) log4r (1.1.9) lorem (0.1.2) macaddr (1.0.0) mail (2.2.15, 1.5.2) maruku (0.6.0) mechanize (1.0.0, 0.9.3) memcache-client (1.7.4) micronaut (0.3.0) mime-types (1.16) mkrf (0.2.3) mocha (0.9.8) mongrel (1.1.5) more (0.1.1) multi_json (0.0.5) multipart-post (1.1.0) mutter (0.5.3) mysql (2.8.1) needle (1.3.0) net-scp (1.0.2) net-sftp (2.0.4, 1.1.0) net-ssh (2.0.15, 1.1.4, 1.0.10) net-ssh-gateway (1.0.1) newrelic_rpm (2.14.0, 2.9.9, 2.9.8, 2.9.3) nkallen-cache-money (0.2.5) nokogiri (1.4.0) open4 (1.0.1) paperclip (2.3.1.1) parseexcel (0.5.2) polyglot (0.3.1, 0.3.0, 0.2.9) rack (1.2.2, 1.2.1, 1.0.1) rack-mount (0.6.14, 0.6.13) rack-rewrite (1.0.2) rack-test (0.5.7, 0.5.3) rails (3.0.5, 3.0.3, 2.3.4, 2.2.2) railties (3.0.5, 3.0.3) rake (0.8.7, 0.8.3) rcov (0.9.6) RedCloth (4.2.2) redis (2.1.1) redis-namespace (0.10.0) resque (1.13.0) rest-client (1.4.2) riddle (1.0.11, 1.0.8) right_aws (1.10.0) right_http_connection (1.2.4) rpx_now (0.6.11) rspec (2.5.0, 1.3.0, 1.2.9, 1.2.7) rspec-core (2.5.1) rspec-expectations (2.5.0) rspec-mocks (2.5.0) rspec-rails (2.5.0, 1.3.2, 1.2.9, 1.2.7) ruby-aws (1.2.0) ruby-graphviz (0.9.21) ruby-ole (1.2.10.1) ruby-opengl (0.60.1) ruby-openid (2.1.6) ruby-prof (0.9.2, 0.8.1) rubyforge (2.0.4, 2.0.3) rubygems-update (1.7.1, 1.6.2) RubyInline (3.8.1) rufus-tokyo (0.1.14) rvm (0.0.98) selenium-webdriver (0.0.14) sequel (3.14.0, 3.9.0, 3.6.0) simple_uuid (0.0.2) sinatra (1.2.1, 1.1.2, 1.0, 0.9.5) slave (1.2.1) smurf (1.0.3) snailgun (1.0.6) spork (0.7.5) spreadsheet (0.6.4.1) sqlite3 (1.3.3) sqlite3-ruby (1.3.3, 1.2.5) stemmer (1.0.1) syntax (1.0.0) technicalpickles-jeweler (1.2.1) term-ansicolor (1.0.5, 1.0.4) Text (1.1.2) thinking-sphinx (1.3.18, 1.3.14) thor (0.14.6) thoughtbot-factory_girl (1.2.2) thrift (0.2.0.4) thrift_client (0.3.3, 0.3.1) tilt (1.2.2) timetrap (1.7.4, 1.4.0, 1.3.0, 1.2.1, 1.2.0, 1.1.3, 1.1.2) treetop (1.4.9, 1.4.8, 1.4.2) tzinfo (0.3.26, 0.3.25, 0.3.24) uuid (2.1.0, 2.0.1) uuidtools (2.1.2, 2.1.1) vegas (0.1.8) vlad (1.3.2) webrat (0.7.0, 0.6.0, 0.4.4) will_paginate (2.3.11) xhtmldiff (1.0.0) xml-simple (1.0.14, 1.0.12) xmpp4r (0.4) ya2yaml (0.26) ZenTest (4.1.4) ---------------------------------------------------------------------- Comment By: Sam Goldstein (samgoldstein) Date: 2011-04-05 11:02 Message: BTW the first environment load was with gem version 1.3.5 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29116&group_id=126 From noreply at rubyforge.org Tue Jun 7 19:50:06 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 7 Jun 2011 19:50:06 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-28945 ] When I request to install 8 gems, it installs 12 Message-ID: <20110607235010.78C44185837F@rubyforge.org> Bugs item #28945, was opened at 2011-02-22 14:56 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28945&group_id=126 Category: `gem install` command Group: None Status: Open Resolution: Accepted Priority: 1 Submitted By: Aaron Patterson (aaronp) Assigned to: Ryan Davis (zenspider) Summary: When I request to install 8 gems, it installs 12 Initial Comment: here is a video: http://www.youtube.com/watch?v=sgWr7lax9G8 Here is the output from my console: [aaron at YPCMC09458 dist (3-0-5-rc)]$ ls actionmailer-3.0.5.rc1.gem activeresource-3.0.5.rc1.gem actionpack-3.0.5.rc1.gem activesupport-3.0.5.rc1.gem activemodel-3.0.5.rc1.gem rails-3.0.5.rc1.gem activerecord-3.0.5.rc1.gem railties-3.0.5.rc1.gem [aaron at YPCMC09458 dist (3-0-5-rc)]$ ls | wc -l 8 [aaron at YPCMC09458 dist (3-0-5-rc)]$ gem list | grep 3.0.5 [aaron at YPCMC09458 dist (3-0-5-rc)]$ sudo gem install * Successfully installed activesupport-3.0.5.rc1 Successfully installed activemodel-3.0.5.rc1 Successfully installed actionpack-3.0.5.rc1 Successfully installed actionmailer-3.0.5.rc1 Successfully installed actionpack-3.0.5.rc1 Successfully installed activemodel-3.0.5.rc1 Successfully installed activerecord-3.0.5.rc1 Successfully installed activeresource-3.0.5.rc1 Successfully installed activesupport-3.0.5.rc1 Successfully installed railties-3.0.5.rc1 Successfully installed rails-3.0.5.rc1 Successfully installed railties-3.0.5.rc1 12 gems installed Installing ri documentation for activesupport-3.0.5.rc1... Installing ri documentation for activemodel-3.0.5.rc1... Installing ri documentation for actionpack-3.0.5.rc1... Installing ri documentation for actionmailer-3.0.5.rc1... Installing ri documentation for actionpack-3.0.5.rc1... Installing ri documentation for activemodel-3.0.5.rc1... Installing ri documentation for activerecord-3.0.5.rc1... Installing ri documentation for activeresource-3.0.5.rc1... Installing ri documentation for activesupport-3.0.5.rc1... Installing ri documentation for railties-3.0.5.rc1... Installing ri documentation for rails-3.0.5.rc1... file 'lib' not found Installing ri documentation for railties-3.0.5.rc1... Installing RDoc documentation for activesupport-3.0.5.rc1... ^[Installing RDoc documentation for activemodel-3.0.5.rc1... Installing RDoc documentation for actionpack-3.0.5.rc1... Installing RDoc documentation for actionmailer-3.0.5.rc1... Installing RDoc documentation for actionpack-3.0.5.rc1... Installing RDoc documentation for activemodel-3.0.5.rc1... Installing RDoc documentation for activerecord-3.0.5.rc1... Installing RDoc documentation for activeresource-3.0.5.rc1... Installing RDoc documentation for activesupport-3.0.5.rc1... Installing RDoc documentation for railties-3.0.5.rc1... Installing RDoc documentation for rails-3.0.5.rc1... file 'lib' not found Installing RDoc documentation for railties-3.0.5.rc1... [aaron at YPCMC09458 dist (3-0-5-rc)]$ ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-06-07 16:50 Message: Hi! Believe it or not, we're moving to github's issue tracker! The pressure to move has been loud and clear, but for the longest time it didn't support the way we worked. Now that it has freeform labels it can support our workflow adequately. There is just one problem: Your bug is here and we don't want to lose you! What we'd like you to do is fairly painless and should only take a few minutes: Please file the _exact_ same ticket on github and provide a link back to this crufty old ticket so we can refer to any previous discussion that occurred. Once the new ticket is made, put a forwarding link to it here and close this ticket out. In a couple weeks, we'll track down the old tickets that are still open and decide what to do with them. We could have done this fairly automatically, but we really want you to do it so you're attached to the ticket and we can still communicate with you and keep a record of it. https://github.com/rubygems/rubygems/issues Thanks, The RubyGems Team ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28945&group_id=126 From noreply at rubyforge.org Tue Jun 7 19:50:07 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 7 Jun 2011 19:50:07 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29169 ] rake creates ruby wrappers around non-ruby executables, causing them to fail Message-ID: <20110607235009.F024C3C809D@rubyforge.org> Bugs item #29169, was opened at 2011-05-05 18:56 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29169&group_id=126 Category: other Group: None Status: Open Resolution: Rejected Priority: 3 Submitted By: Kevin Olbrich (olbrich) Assigned to: Ryan Davis (zenspider) Summary: rake creates ruby wrappers around non-ruby executables, causing them to fail Initial Comment: when providing executables with a gem, they get wrapped in a ruby wrapper that provides some support for using previous versions of a gem. If the executable is not a ruby file (e.g., a bash script, php, etc..) then the wrapper will fail. Suggestions: 1. allow the gemspec to force the gem to be installed with '--no-wrapper' and leave it to the developer to properly wrap executables. 2. check the shebang line of the executable and skip wrapping for anything that explicitly uses something other than ruby ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-06-07 16:50 Message: Hi! Believe it or not, we're moving to github's issue tracker! The pressure to move has been loud and clear, but for the longest time it didn't support the way we worked. Now that it has freeform labels it can support our workflow adequately. There is just one problem: Your bug is here and we don't want to lose you! What we'd like you to do is fairly painless and should only take a few minutes: Please file the _exact_ same ticket on github and provide a link back to this crufty old ticket so we can refer to any previous discussion that occurred. Once the new ticket is made, put a forwarding link to it here and close this ticket out. In a couple weeks, we'll track down the old tickets that are still open and decide what to do with them. We could have done this fairly automatically, but we really want you to do it so you're attached to the ticket and we can still communicate with you and keep a record of it. https://github.com/rubygems/rubygems/issues Thanks, The RubyGems Team ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-05-31 16:26 Message: I don't know of a good way to do this that works across platforms and makes sense. Rubygems is for ruby. If a file is in your gem's bindir and listed as a gem executable, it should be ruby. If your gem has "special needs" then it should do it out of band, like create a Rakefile that does your special steps for you and list the Rakefile as an extension in the spec. Or just use a post-install message telling people to install with --no-wrapper. Lemme know if I didn't understand something. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29169&group_id=126 From noreply at rubyforge.org Tue Jun 7 19:50:06 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 7 Jun 2011 19:50:06 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29075 ] need for a post_install hook Message-ID: <20110607235010.B40033C809F@rubyforge.org> Bugs item #29075, was opened at 2011-03-11 05:36 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29075&group_id=126 Category: `gem install` command (extensions) Group: next Status: Open Resolution: Rejected Priority: 3 Submitted By: Torsten Curdt (tcurdt) Assigned to: Ryan Davis (zenspider) Summary: need for a post_install hook Initial Comment: While there is Gem.post_install this cannot be used for gems that want to run some code on installation. In my particular case I need to compile some C++ code -a command line tool- that the gem depends on. It does not come with an extension though. Since there is no post_install hook exposed to the gem lifecycle people use the extconf for things like this. Since that one makes the assumption of building an extension, leaving out the create_makefile() results in Building native extensions. This could take a while... ERROR: Error installing ... ERROR: Failed to build gem native extension. No builder for extension 'path/to/extconf.rb' Which result in people doing things like this http://blog.costan.us/2008/11/post-install-post-update-scripts-for.html The best solution would certainly be to have some gem lifecyle hooks. But just making less assumption on the extension building would already be a first step. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-06-07 16:50 Message: Hi! Believe it or not, we're moving to github's issue tracker! The pressure to move has been loud and clear, but for the longest time it didn't support the way we worked. Now that it has freeform labels it can support our workflow adequately. There is just one problem: Your bug is here and we don't want to lose you! What we'd like you to do is fairly painless and should only take a few minutes: Please file the _exact_ same ticket on github and provide a link back to this crufty old ticket so we can refer to any previous discussion that occurred. Once the new ticket is made, put a forwarding link to it here and close this ticket out. In a couple weeks, we'll track down the old tickets that are still open and decide what to do with them. We could have done this fairly automatically, but we really want you to do it so you're attached to the ticket and we can still communicate with you and keep a record of it. https://github.com/rubygems/rubygems/issues Thanks, The RubyGems Team ---------------------------------------------------------------------- Comment By: Torsten Curdt (tcurdt) Date: 2011-04-11 01:04 Message: Thanks, Ryan. If that's the case I think we can close this issue ...as soon as this is part of the documentation at least. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-04-08 12:30 Message: Torsten, yeah. You just set your gemspec's extensions field to point to the Rakefile: s.extensions = ["notext/#{self.name}/Rakefile"] and the rakefile should work like below or however you want it to work... it's just rake so you can do anything you want. ---------------------------------------------------------------------- Comment By: Torsten Curdt (tcurdt) Date: 2011-03-15 00:02 Message: Ryan, can elaborate or point me to an example how to do a "rake-based extension"? IIUC this means providing a Rakefile (or Makefile?) instead of the generated by the extconf? Still have your test project around? ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-03-14 14:01 Message: Just to make sure I understand: you have a pure ruby gem that calls out to a binary that you want to provide (build and install) via the gem. If that is accurate, I don't think that extra post_install hooks are the right way to go here. I think you can make this work via "normal" mechanisms. I think what you want to do is design a rake-based extension but then have that rakefile build and install your binary instead of a shared library. I just simulated this with a simple hoe-based project that had 'notext/blah/Rakefile' as it's extension and that rakefile just had: task :default => :build task :build do puts "building my cmdline tool!" touch "happy" end Upon packaging and installing, 'happy' was created inside the notext dir of the install. ---------------------------------------------------------------------- Comment By: Torsten Curdt (tcurdt) Date: 2011-03-14 11:55 Message: You can turn it like you want but building binaries is what rubygems is already doing today. They just get a different linker treatment. Not sure why one make such hard distinction there. Abuse scenarios are a bogus argument as long as the extconf (or for that matter - any code from the gem) gets executed. ---------------------------------------------------------------------- Comment By: Marcus Rueckert (darix) Date: 2011-03-14 11:02 Message: and any packaging system that uses post install hooks for building files *is* broken. i didnt even refer to potential abuse scenarios yet, building native extensions for ruby is certainly in the scope of rubygems. building binaries that get installed somewhere definitely is not. ---------------------------------------------------------------------- Comment By: Torsten Curdt (tcurdt) Date: 2011-03-14 10:04 Message: If that binary was something that would make sense outside of the gem I would agree - but it doesn't. Following your arguments all native code should live somewhere else - including the normal extensions. That would add a complexity to the system I don't see worth having. A post_install hook certainly gives room for abuse but it's a common pattern found in the various packaging systems. Not sure I would call this a broken feature. In fact I think the current build in assumptions are even worse. ---------------------------------------------------------------------- Comment By: Marcus Rueckert (darix) Date: 2011-03-14 08:47 Message: imho this is just the wrong approach, intree packaging like that just sucks. for users as for packagers. maybe the user has your binary installed already just outside of $PATH? while you could walk over $PATH and check if a binary with the desired name exists, you couldnt be sure that behind the filename is really the app you are expecting and that the version is compatible. handle the absence of the binary properly in your code and document for the user that a certain binary is required for proper functioning of your gem. I would really object adding a broken feature like this. ---------------------------------------------------------------------- Comment By: Torsten Curdt (tcurdt) Date: 2011-03-14 08:07 Message: You are probably right. As long as it is tracked as feature or bug I am fine. Thanks - the short term thing works. It's just ugly :) ---------------------------------------------------------------------- Comment By: Jon Forums (jonforums) Date: 2011-03-14 08:04 Message: Fair. IMO this issue should reappear as a feature request rather than stay a bug. And that would likely lead to relooking at plugin/hook visibility. I don't know what Eric wants for next steps on this, but since he asked you to open the issue, maybe it's enough to leave it as a bug. Good luck with whatever short-term solution you choose. ---------------------------------------------------------------------- Comment By: Torsten Curdt (tcurdt) Date: 2011-03-14 07:22 Message: Sorry, but the --init is more a work around than really an option. IMO a post_install hook for a gem is quite a natural thing to expect. If that's not on the table extconf should at least not make all those assumptions people hack around today. If you just close this issue people will continue to abuse the extconf like I am doing, too now. IMO an empty extconf should just not result in an error and we would be OKish. ---------------------------------------------------------------------- Comment By: Jon Forums (jonforums) Date: 2011-03-14 06:51 Message: While you could go down the plugin/hook path and split things something like... https://github.com/jonforums/prething https://github.com/jonforums/thing I think it's a bad fit for what you're trying to do...could become a tarbaby trying to keep the `prething` plugin from affecting other gems and coordinating with your main gem. Try building/installing the `prething` and see how globally it affects RG ops. Probably faster and more robust to add an `--init` to your gem's `bin\somthing` executable and document your gem's two-step install process in a `Gem::Specification.post_install_message` and your project doc. Any reason to keep this listed as an open RG bug? ---------------------------------------------------------------------- Comment By: Jon Forums (jonforums) Date: 2011-03-12 07:18 Message: That snippet from our install script results in a rubygems/defaults/operating_system.rb file being generated similar to the following: # :DK-BEG: override 'gem install' to enable RubyInstaller DevKit usage Gem.pre_install do |gem_installer| unless gem_installer.spec.extensions.empty? unless ENV['PATH'].include?('C:\DevKit\mingw\bin') then Gem.ui.say 'Temporarily enhancing PATH to include DevKit...' if Gem.configuration.verbose ENV['PATH'] = 'C:\DevKit\bin;C:\DevKit\mingw\bin;' + ENV['PATH'] end ENV['RI_DEVKIT'] = 'C:\DevKit' ENV['CC'] = 'gcc' ENV['CPP'] = 'cpp' ENV['CXX'] = 'g++' end end # :DK-END While my usage is fairly simple and the only mildly clever parts are (a) checking whether a native extension is being installed, and (b) wrapping the code snippet in markers so I can manage non-clobbering/upgrades of existing operating_system.rb files, I'm still betting that you could use `system` to call out to your toolchain and build your C++ tool in a similar way. It's the combination of the filename/location in combination with the block to Gem.pre_install which sets the pre-install hook that RG calls at the appropriate time during an install. These two places in the source should help: https://github.com/rubygems/rubygems/blob/master/lib/rubygems.rb#L65-82 https://github.com/rubygems/rubygems/blob/master/lib/rubygems/installer.rb#L140 ---------------------------------------------------------------------- Comment By: Torsten Curdt (tcurdt) Date: 2011-03-12 02:55 Message: @Jon: Still don't quite understand when you are setting that hook. Why would that code be called on a 'gem install' ? ---------------------------------------------------------------------- Comment By: Jon Forums (jonforums) Date: 2011-03-11 08:05 Message: In the DevKit (MSYS/MinGW toolchain for Windows) subproject of the RubyInstaller we have a Ruby install script which dynamically builds a gem override script that uses the pre-install hook to setup the environment for building native gems on Windows using the DevKit: https://github.com/oneclick/rubyinstaller/blob/master/resources/devkit/dk.rb.erb#L46-65 Basically, it automagically brings the DevKit toolchain into the environment when doing something like `gem install bson_ext` Thinking out loud, but I wonder if you can do something similar but use `system` or `IO.popen` to optimistically compile your gem's C++ dependency before the install and abort if you get any errors. Might also want to check/cleanup in post-build. A wild-eyed idea, but it might work if you can split things into "pre-build dependencies" and "build extension" and abort if things go badly. ---------------------------------------------------------------------- Comment By: Torsten Curdt (tcurdt) Date: 2011-03-11 07:46 Message: Maybe I misunderstood but I think Eric said on IRC that the existing post_install is not for gems. Which is why he asked me to open this issue. Jon, can you give an example how that would work? Whether it is pre or post install is not important to me. It's just that one might want to build more than just extension on install. I got that working by abusing the extconf to execute my build and creating an empty Makefile. But that smells. ---------------------------------------------------------------------- Comment By: Jon Forums (jonforums) Date: 2011-03-11 07:13 Message: Can you split things up to use the pre-install and post-build hooks which as of 1.5.0 that can cancel gem installation...optimistically compile in the pre-install and abort if needed in either pre-install or post-build? http://blog.segment7.net/2011/01/31/rubygems-1-5 ---------------------------------------------------------------------- Comment By: Torsten Curdt (tcurdt) Date: 2011-03-11 05:54 Message: Then you also cannot allow native builds. Where is the difference? ---------------------------------------------------------------------- Comment By: Luis Lavena (luislavena) Date: 2011-03-11 05:44 Message: I would say no to this. Most of the users do not check what the gem do inside, so there is a huge potential of security risks on this. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29075&group_id=126 From noreply at rubyforge.org Tue Jun 7 19:50:09 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 7 Jun 2011 19:50:09 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29176 ] Scary warnings are scaring helpless developers who can't do a thing about it Message-ID: <20110607235010.9BE1D18583D3@rubyforge.org> Bugs item #29176, was opened at 2011-05-06 13:07 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29176&group_id=126 Category: `gem` commands (other) Group: None Status: Open Resolution: None Priority: 3 Submitted By: Alex Chaffee (alexch) Assigned to: Ryan Davis (zenspider) Summary: Scary warnings are scaring helpless developers who can't do a thing about it Initial Comment: Suddenly anyone using "gem" is seeing many repetitions of lines like this: NOTE: Gem::Specification#default_executable= is deprecated with no replacement. It will be removed on or after 2011-10-01. Gem::Specification#default_executable= called from /Users/chaffee/.rvm/gems/ruby-1.9.2-p0/specifications/thin-1.2.7.gemspec:10. Many of my students are completely freaking out since something that's supposed to just work -- e.g. "gem install rails" or "gem list"-- is now spewing a huge amount of scary noise about things which are currently working just fine, and which they have no ability to affect. Even developers with the acumen to be able to read, understand, and react to these messages are wasting time googling, often fruitlessly, since even if they find Ryan's blog post, and run "gem pristine --all --no-extensions", it doesn't make all the warnings disappear. Here's my suggested fix, in three independent parts. 1. Stop repeating the same message again and again; instead set a global flag (already_scared_user?) and STFU if it happens for a different gem 2. Put the advice about running "gem pristine --all --no-extensions" in the error message instead of forcing people to google to find a workaround 3. Before the warning, try to rewrite the offending gemfile yourself, as if the user had run "gem pristine". If the rewrite fails, only then scare the user. And please remember that the "gem" command is the user interface to the entire world of Ruby development, for people of all experience levels. You have a responsibility not to scare off our friends, new and old. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-06-07 16:50 Message: Hi! Believe it or not, we're moving to github's issue tracker! The pressure to move has been loud and clear, but for the longest time it didn't support the way we worked. Now that it has freeform labels it can support our workflow adequately. There is just one problem: Your bug is here and we don't want to lose you! What we'd like you to do is fairly painless and should only take a few minutes: Please file the _exact_ same ticket on github and provide a link back to this crufty old ticket so we can refer to any previous discussion that occurred. Once the new ticket is made, put a forwarding link to it here and close this ticket out. In a couple weeks, we'll track down the old tickets that are still open and decide what to do with them. We could have done this fairly automatically, but we really want you to do it so you're attached to the ticket and we can still communicate with you and keep a record of it. https://github.com/rubygems/rubygems/issues Thanks, The RubyGems Team ---------------------------------------------------------------------- Comment By: Chad Woolley (thewoolleyman) Date: 2011-06-02 08:50 Message: https://github.com/rubygems/rubygems/pull/66#issuecomment-1281426 ---------------------------------------------------------------------- Comment By: William Denniss (divzero) Date: 2011-05-25 04:23 Message: +1 that it would be good to reduce the 'scaryness'/volume of these warnings. I was setting up rails on a new machine for a colleague today. He saw all the errors and assumed the install was broken until I assured him it wasn't. I think it's good to have deprecation warnings ??but having so many, and for something that that needs to be fixed by the gem maintainers and not end-user-developers, doesn't seem to help. We were all 'helpless developers' once don't forget! Pull request #59 seems to fit the bill. ---------------------------------------------------------------------- Comment By: Chad Woolley (thewoolleyman) Date: 2011-05-24 17:05 Message: We are now getting duplicate pull requests in addition to Alex's (https://github.com/rubygems/rubygems/pull/66#issuecomment-1232323). May we please have the active maintainers weigh in on whether or not Alex's pull request can or cannot be merged? We can probably arrange to discuss on IRC if that is necessary... ---------------------------------------------------------------------- Comment By: Chad Woolley (thewoolleyman) Date: 2011-05-22 16:38 Message: Is there any reason not to merge Alex's patch? https://github.com/rubygems/rubygems/pull/59 He stepped up and wrote some code to make the situation better, and had it code-reviewed by Evan. Can we at least merge that or give feedback? ---------------------------------------------------------------------- Comment By: Jordan Sissel (jordansissel) Date: 2011-05-22 14:06 Message: I suspect this ticket not going to be resolved and is falling on deaf ears the ratio of "suck it up" responses to the "this sucks, please help" comments. If this is thie case, please just close this ticket with a resolution of whatever rubyforge's equivalent of "won't fix" with relevant links to workarounds. ---------------------------------------------------------------------- Comment By: Beoran Aegul (beoran) Date: 2011-05-22 01:10 Message: +1 for solution 1. Running gem pristine broke my rubygems, so I think it's a non-solution. I understand the need to clean up rubygems, but trying to force the whole ruby world to upgrade their gems specs so suddenly is not a good idea, IMHO. Not to mention many useful gems out there that are not maintained actively anymore. Kind Regards, B. ---------------------------------------------------------------------- Comment By: Alex Chaffee (alexch) Date: 2011-05-18 13:45 Message: Ping. My patch https://github.com/rubygems/rubygems/pull/59 doesn't change the inner workings at all, just improves the way deprecations are reported. Given that the idea is to get people to pay attention to them, it seems like people are more likely to pay attention to an organized list than a disorganized flood (especially since the list removes duplicates). Evan has code reviewed the patch and I implemented all his suggestions. ---------------------------------------------------------------------- Comment By: Luis Lavena (luislavena) Date: 2011-05-12 14:58 Message: Ryan, I think I did these steps before 1.8.2, I haven't tried it yet. Also since all my gems are fixed now, can't test again :-) ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-05-12 14:19 Message: Luis, unless I'm not understanding the rvm gem setup correctly, there is no need to do the `rvm use` line anymore. pristine had a bug with multiple repos that was fixed in 1.8.2. ---------------------------------------------------------------------- Comment By: Scott Tadman (tadman) Date: 2011-05-12 09:44 Message: Thanks, Luis, for that tip. I guess that means to upgrade rubygems the user is obligated to: rvmsudo bash gem pristine --all rvm use 1.9.2-p180 at global gem pristine --all Where this is documented other than this ticket, I have no idea. If I hadn't spent hours trying to remedy this, I would've just reverted to gem 1.6.0 and called it a day. If the intent of these warnings is to get people to upgrade, I have a feeling the opposite thing will occur. ---------------------------------------------------------------------- Comment By: Luis Lavena (luislavena) Date: 2011-05-12 08:22 Message: @Scott Tadman: gem pristine with "--no-extensions" will not fix gems that have extensions, that includes rcov, json, perftools. For that, you need "gem pristine" alone. As for rake, it is placed in the global namespace of RVM, so you need to switch to that namespace and correct it: rvm use 1.9.2-p180 at global gem pristine rake Then switch to your normal gemset. ---------------------------------------------------------------------- Comment By: Scott Tadman (tadman) Date: 2011-05-12 08:11 Message: Further investigation reveals that Jeweler's generated .gemspec file is affected by the version of rubygems installed, and that if building against a newer rubygems it will not put in the default_executable= call, so at least that much is fixed. However, the catch-22 here is that you need to build using a newer version of rubygems, which because of all the crazy warnings you get, I'm sure a lot of developers would avoid, instead reverting to an earlier, safer version. I have run gem pristine --all --no-extensions over six times on an OS X rvm-based Ruby 1.9.2 set of system gems and I'm still getting warnings. The first pass removed most, the second some, and the rest virtually none. I'm not sure why this needs to be run more than once in the first place, nor why this is the responsibility of the user. Now anything that even touches rubygems ends up getting lit up with warnings, the final few of which appear to be the most stubborn: NOTE: Gem::Specification#default_executable= is deprecated with no replacement. It will be removed on or after 2011-10-01. Gem::Specification#default_executable= called from /opt/local/rvm/gems/ruby-1.9.2-p180 at global/specifications/rake-0.8.7.gemspec:10. NOTE: Gem::Specification#default_executable= is deprecated with no replacement. It will be removed on or after 2011-10-01. Gem::Specification#default_executable= called from /opt/local/rvm/gems/ruby-1.9.2-p180/specifications/json-1.5.1.gemspec:10. NOTE: Gem::Specification#default_executable= is deprecated with no replacement. It will be removed on or after 2011-10-01. Gem::Specification#default_executable= called from /opt/local/rvm/gems/ruby-1.9.2-p180/specifications/perftools.rb-0.5.6.gemspec:10. NOTE: Gem::Specification#default_executable= is deprecated with no replacement. It will be removed on or after 2011-10-01. Gem::Specification#default_executable= called from /opt/local/rvm/gems/ruby-1.9.2-p180/specifications/rcov-0.9.9.gemspec:11. (in /Users/tadman/git/pigeon) It is worrying that the pristine operation not only produces ~500KB of warnings when processing its various things which buries any actual errors in the process. Maybe there's a reason why these gems can't be pristined properly, but it gets lost in the hurricane of warnings. ---------------------------------------------------------------------- Comment By: Mike Bethany (mikbe) Date: 2011-05-12 00:36 Message: The deprecation warnings made it virtually impossible to work. Every time autotest ran I would have a screen full of gobbledygook I had to sort through, very annoying. I wrote Chicken Little to disable the deprecation warnings just for the two major offenders. You can install the gem with: `gem install chicken_little` then run it `chicken_little install` You can also just go in and edit the RubyGems specification.rb file yourself and comment out those lines. Source: https://github.com/mikbe/chicken_little RubyGems: https://rubygems.org/gems/chicken_little P.S. RubyGems 1.8.2 seems to be broken in Ubuntu 10.10. Funny enough in the specification.rb file at line 277. Though it seems to be OK in OS X 10.6.7. ---------------------------------------------------------------------- Comment By: Alex Chaffee (alexch) Date: 2011-05-11 16:25 Message: I've gone ahead and made a patch. My fork of rubygems still prints out warnings, but after the first warning, it buffers up all remaining warnings and then emits them at_exit in a somewhat nicer report format, like this: Some of your installed gems called deprecated methods. See http://blog.zenspider.com/2011/05/rubygems-18-is-coming.html for background. Use 'gem pristine --all' to fix or 'rubygems update --system 1.7.2' to downgrade. TestDeprecate::Thing#foo is deprecated; use bar instead. It will be removed on or after 2099-03-01. called from /Users/chaffee/dev/rubygems/test/rubygems/test_deprecate.rb:174 called from /Users/chaffee/dev/rubygems/test/rubygems/test_deprecate.rb:175 called from /Users/chaffee/dev/rubygems/test/rubygems/test_deprecate.rb:177 TestDeprecate::Thing#goo is deprecated; use bar instead. It will be removed on or after 2099-04-01. called from /Users/chaffee/dev/rubygems/test/rubygems/test_deprecate.rb:176 I also pulled in the "--no-warnings" patch, but set the default back to "show all warnings" (i.e. skip=false). https://github.com/alexch/rubygems/commit/5572c2c1bb88e2e1b55b8d62 3fe4ef58a954c2a1 ---------------------------------------------------------------------- Comment By: Scott Tadman (tadman) Date: 2011-05-11 11:06 Message: Part of this problem is that Jeweler, a gem used by many authors to build their gems, inserts the default_executable= line in all the .gemspec files it produces. This is something done without the knowledge of the authors, and as one, I'm not even sure how to turn it off. I'll have to do more research. In the mean-time I need to live with the guilt and shame of causing warnings for everyone using anything I've made. I do want to keep up to date. I use Ruby 1.9.2 and the latest everything for new projects, but there are many legacy applications I'm involved with that for reasons of budget, dependency hell, or otherwise, are constrained to specific older versions. What I'm asking is why methods can't be deprecated by rendering them non-functional instead of causing things to explode by calling methods that no longer exist. It is common practice amongst UNIX shell utilities to have non-functional arguments for this very reason. I'm not saying to support the API, but at least make it mostly compatible with the newest spec even if it may not perform exactly as intended. For instance, most browsers don't support the tag, but they also don't refuse to render the page because of a lack of support. Once again, these are not my "decrepit needs", but rather the fact that there are hundreds if not thousands of gems out there with this mostly useless call to default_executable= as inserted by Jeweler and others that could be harmlessly ignored. I will post another ticket relating to the warnings later if I can replicate it. I have mostly fixed the issue using the pristine option which should be advertised more clearly or, better yet, done automatically when gem is updated to the newest release. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-05-11 02:02 Message: Scott, Please file a ticket with details and, if possible, reproduction steps showing that rolling back to 1.7.2 still has deprecation warnings that were added to 1.8.0. If it isn't too much to ask, please file a ticket with details and, if possible, reproduction steps showing "literally, 4000+ lines of warnings when running ordinary rake tasks" after running `gem pristine --all --no-extensions`. Do note that I suspect there is a bug in `gem pristine` in scenarios like using rvm w/ multiple gem directories... I don't have a repro for that yet. Finally, the majority of these deprecations are created _by_ rubygems in gemspecs and are fixable _by_ rubygems (pristine bugs notwithstanding)... Those warnings that are left afterwards represent real usage of methods that ARE going away. You state that you're intentionally running old gems on your apps but you insist on updating rubygems & bundler... You're going to update to a version that doesn't have the implementation one of your decrepit needs. What is your plan for that? Do you really think it reasonable that we should keep around API supporting everything all the way back to 2004? I'm sorry, but that just doesn't seem sane to me. We have to move on, even if you won't. ---------------------------------------------------------------------- Comment By: Scott Tadman (tadman) Date: 2011-05-10 21:37 Message: This issue is driving me berserk. I've pristined, I've rolled back to 1.7.2 like the Germans retreating from Russia and still I'm getting nagged and hassled. When something like default_executable is specified in default gemspec files that Jeweler produces and other templates that many have used to build out their gemspecs, it does seem like a bit of a nuisance. Maybe it's better to rescind support for it and turn it into a method that does nothing simply for compatibility reasons. Document the method as deprecated and non-functional for the curious. Lobby to get it removed from examples and places like Jeweler. I have applications with dozens of deliberately old versions of gems because the associated applications aren't up to date and upgrading causes problems. The one thing I do want to keep up to date is support utilities like gem and bundler, though, and getting, literally, 4000+ lines of warnings when running ordinary rake tasks is not helping. Even if I nagged and hassled every single gem builder, and seriously, I have nagged many about Ruby 1.9 issues, this still wouldn't matter because I simply have older versions of gems installed that cannot be patched without altering the space-time continuum. This is basically condemning me to using an antiquated version of gem so long as I have even one squeaky wheel in the whole system, as a single out of date gem will produce warnings for every gem related operation. When installing a new gem, if strictly necessary, it could say that the .gemspec is out of date and should be updated while hinting at the obscure pristine command as to how that might remedy it. I have wildly different versions of gem installed on my systems, but it's as if every time I go to update to the latest I get slapped in the face with something like this. I honestly wonder how other people have fared. After a lot of fussing about, experimenting with different approaches and attempting to be as unobtrusive as possible, I have come up with a patch that enables Deprecate.skip by default and also allows the setting to be toggled on or off as desired using the --warnings or --no-warnings options for install. After inspecting the implementation of this, which appears to have erupted into the root namespace as the module Deprecate, and without any sort of unit test, I have inverted the default because warnings are generated before command options are processed and there does not appear to be any other way. Patch: https://gist.github.com/965921 ---------------------------------------------------------------------- Comment By: Stephen Bannasch (stepheneb) Date: 2011-05-10 20:13 Message: For now I'm using this solution: gem update --system 1.7.2 Thanks Luis -- I didn't remember how easy it was to downgrade RubyGems. After running: gem pristine --all --no-extensions -- running a single spec test In my rails 2.3.11 project with RubyGems 1.8.1 generates 317 lines of warnings before I see the 10 lines of results: https://gist.github.com/965850 It's certainly annoying enough to get me to plan to fix my gem (jnlp) but my one gem is just a tiny bit of the noise in general. ---------------------------------------------------------------------- Comment By: Jordan Sissel (jordansissel) Date: 2011-05-10 18:36 Message: FWIW, I support deprecations, but these warning messages are going to users, not developers. And that sucks. For example, all my ruby nagios alerts are filled, now, with pointless warnings about libraries my code is *not* using. So many warnings, in fact, that the test code's output is lost. This warning should pop up when developers run 'gem build foo.gemspec' and no other time. Why? Consider a user who has code that relies on rake '0.8.0' explicitly. You can't actually fix 'rake 0.8.0' on rubygems.org because you can't overwrite an existing release (for good reason). So now, for eternity, this user is stuck with warning messages. ---------------------------------------------------------------------- Comment By: Alex Chaffee (alexch) Date: 2011-05-10 10:55 Message: Chad - A two-line warning per gem would still be super noisy. One compromise would be to queue up a list of offending gems per warning and then emit them all on_exit in a single line. As for patches, as I said before, I'd be happy to spend my time working on that, but not until I get the goahead from a member of the core team (especially considering that first comment). ---------------------------------------------------------------------- Comment By: Scott Tadman (tadman) Date: 2011-05-10 09:26 Message: I just "upgraded" gem and now I'm greeted with over a thousand lines of warnings, nearly one for every gem I have installed on my system. It doesn't just warn for gems I use, but any gems I might happen to have that are out of date. The message itself is meaningless as there's really nothing I can do about it, and further, it doesn't seem like ignoring that directive instead of complaining about it would have much of an effect on the end user. Since when is it the responsibility of gem users to hassle gem builders into compliance? Why can't the gem build operation give the builder a hard time instead? Why can't rubygems.org reject the gem out of protest? As a note, I'm also getting a kabillion identical warnings apparently from rubygems itself: Gem::SourceIndex#add_spec called from /opt/local/rvm/rubies/ree-1.8.7-2011.03/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:127. NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It will be removed on or after 2011-11-01. Gem::SourceIndex#add_spec called from /opt/local/rvm/rubies/ree-1.8.7-2011.03/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:127. NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It will be removed on or after 2011-11-01. Gem::SourceIndex#add_spec called from /opt/local/rvm/rubies/ree-1.8.7-2011.03/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:127. NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It will be removed on or after 2011-11-01. Gem::SourceIndex#add_spec called from /opt/local/rvm/rubies/ree-1.8.7-2011.03/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:127. NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It will be removed on or after 2011-11-01. Gem::SourceIndex#add_spec called from /opt/local/rvm/rubies/ree-1.8.7-2011.03/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:127. NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It will be removed on or after 2011-11-01. Gem::SourceIndex#add_spec called from /opt/local/rvm/rubies/ree-1.8.7-2011.03/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:127. NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It will be removed on or after 2011-11-01. Gem::SourceIndex#add_spec called from /opt/local/rvm/rubies/ree-1.8.7-2011.03/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:127. NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It will be removed on or after 2011-11-01. Gem::SourceIndex#add_spec called from /opt/local/rvm/rubies/ree-1.8.7-2011.03/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:127. NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It will be removed on or after 2011-11-01. ---------------------------------------------------------------------- Comment By: Chad Woolley (thewoolleyman) Date: 2011-05-08 11:43 Message: I agree, it would be nice if the deprecation warning were once per gem (NOT once for all gems as Alex suggested; that would defeat the purpose of getting people to complain to gem authors to fix their specs) However, I don't see any patches or even failing tests attached to this ticket yet... ---------------------------------------------------------------------- Comment By: Loren Segal (lsegal) Date: 2011-05-08 09:40 Message: Ryan, I'm not too sure if you read the entirety of my message. Just in case, I'll summarize again: 1. I agree that having warnings telling developers to update their APIs is good. I believe I said that. (Feel free to check) 2. The issue in this report is not about whether the warnings should exist or not, because everybody here agrees they should. The issue is how often they need to be printed. Given that I am suggesting the same fix as Alex, I don't see how this falls out of the scope of the ticket. 3. My feedback was not (entirely) a "me too". I am simply trying to provide extra information regarding the breadth of this issue that others might not be aware of; specifically that `gem pristine --all` is not a complete solution to this issue, at least it does not guarantee the hiding of all warning *spam* (remember, not arguing about first-time warnings, but complete page-spam). As far as I know, that problem was not yet discussed. I'm of the opinion that all relevant information should be provided with a bug report. There's no need to jump down users throats for providing extra information, so please try to use your indoor voice. 3. I don't see why modifying the warnings to show once (per method) needs to be controversial. It seems like quite a simple and reasonable change, at least to me. Is it not reasonable to you? Why not? Finally, as far as I know, open source relies on feedback from the community; certainly a tool that is widely used and part of Ruby's standard library deserves feedback from all of the community. Telling users that they are not allowed to voice their opinion on an open ticket simply does not compute. I'm therefore politely declining your invitation to "get off this ticket". Though, I suppose this should have prefaced the response with this note instead. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-05-08 01:56 Message: No worries. ---------------------------------------------------------------------- Comment By: Justin Collins (presidentbeef) Date: 2011-05-07 23:57 Message: Sorry, my mistake. I didn't notice that gem was called out specifically. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-05-07 23:54 Message: Justin, As described at http://blog.zenspider.com/2011/05/rubygems-18-is-coming.html and elsewhere, rake is one of those unfortunate gems that explicitly uses the deprecated API in their gemspec. Please file a bug on the rake bug tracker. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-05-07 23:53 Message: Loren, Get off this ticket. Everything you just described falls outside of the scope of this ticket. Specifically: "helpless developers". The point of having deprecations at all is to get those "hundreds" of libraries that use deprecated API to update their code. If you want to "me too", then yippie... but your hyperbole isn't a "me too" it is a completely separate issue (and one I will more readily reject). ---------------------------------------------------------------------- Comment By: Justin Collins (presidentbeef) Date: 2011-05-07 23:19 Message: I did a fresh install of 1.9.2 with rvm, then upgraded Ruby Gems. The only gem installed was "rake", and after running "gem pristine --all", "gem pristine --all --no-extensions", and "gem pristine rake", I still get the following error: NOTE: Gem::Specification#default_executable= is deprecated with no replacement. It will be removed on or after 2011-10-01. Gem::Specification#default_executable= called from /home/justin/.rvm/gems/ruby-1.9.2-p180 at global/specifications/rake-0.8.7.gemspec:10. ---------------------------------------------------------------------- Comment By: Loren Segal (lsegal) Date: 2011-05-07 22:40 Message: I have to agree with the severity of this issue. The problem is unfortunately not just limited to the `gem` binary. Any library making use of deprecated APIs will also get these warnings ad-infintum, so gem pristinie --all doesn't solve this issue, only small one part of it. For example, any gem that makes use of SourceIndex will see these deprecation warnings on each usage. There are currently hundreds of libraries that make use of this class, as per my latest search on codesearch: http://codesearch.google.com/codesearch?q=SourceIndex+lang:ruby and http://codesearch.google.com/codesearch?q=Gem.source_index+lang%3Aruby You might get lucky and just see a few of these warnings, but if the method is called within a loop, RubyGems will not be forgiving, and spam you many, many, times (see http://codesearch.google.com/codesearch/p?hl=en#L18QHnAzSFA/bin/minigem&q=Gem.source_index%20lang:ruby&sa=N&cd=46&ct=rc for just one random example). In some cases, this output may even render the lib/tool completely unusable, especially if it relies heavily on console output. Because of that possibility, an otherwise innocuous (and transitional) warning can become a "severe" compatibility bug. Just like Alex, I'm all for warnings, but I foresee a lot of developers scrambling to provide fixes for their users in the coming months, especially in the cases where their tools start scrolling pages of warnings just because of one method call. I'm not sure devs or users will be too happy about this. Fortunately the fix is simple, as Alex pointed pointed out. I think it would be sensible to add the suggested "already_scared_user?" flag; it can probably be done on a per method name granularity. Given that all of the deprecations are wrapped inside a Deprecation module AFAIK(?), this should be pretty simple to add. ---------------------------------------------------------------------- Comment By: Luis Lavena (luislavena) Date: 2011-05-06 15:04 Message: Which gem was not solved by gem pristine --all? please provide complete output, we can't help without the output. As for drowning on this issue: revert back to 1.7.2 There is no easy way to solve existing gem specifications without doing gem pristine --all And we can't help solve the others without people telling us which ones didn't get fixed for us to look at *why*. So, I know were are you coming from, heck, I work on Windows, what more weird scenario for failures could be than that? And even so, gem pristine --all solved all the issues. Help us help you. ---------------------------------------------------------------------- Comment By: Alex Chaffee (alexch) Date: 2011-05-06 14:41 Message: Luis - thanks, "gem pristine -all" has fixed most -- but still not quite all -- of the messages. Warnings are indeed good, but only until they become noise. That is extra bad since it can drown out other important information, especially for less experienced people who are mystified by everything coming down on the console. One reason I'm concerned about this is that tonight in two different cities we're doing a Railsbridge Ruby For Women Workshop Install Fest, and most of the students won't understand what's going on, and the volunteers may not either. This will add chaos to an already chaotic and frustrating session. Not your problem, I know, but I wanted you to know where I'm coming from. ---------------------------------------------------------------------- Comment By: Luis Lavena (luislavena) Date: 2011-05-06 13:38 Message: gem pristine --all --no-extensions will fix the gems that do not have extensions You need to do gem pristine -all, but that will not accept parameters for each gem. In my case I didn't require additional parameters to each gem so a simple gem pristine --all solved all the warnings. Warnings are good, and as always, you can rollback to previous versions if you find it doesn't work for you: gem update --system 1.7.2 ---------------------------------------------------------------------- Comment By: Alex Chaffee (alexch) Date: 2011-05-06 13:27 Message: I wasn't trying to be inflammatory. This is a real problem, wasting the real time of real people across the world. And I'd be happy to submit a patch but somehow it doesn't seem likely you'd accept it. ---------------------------------------------------------------------- Comment By: Erik Hollensbe (erikh) Date: 2011-05-06 13:22 Message: Really? Don't you have anything better to do than to post inflammatory shit to this tracker? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29176&group_id=126 From noreply at rubyforge.org Tue Jun 7 19:50:09 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 7 Jun 2011 19:50:09 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29198 ] gem rdoc uses some deprecated methods Message-ID: <20110607235011.D08BE3C809B@rubyforge.org> Bugs item #29198, was opened at 2011-05-10 16:56 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29198&group_id=126 Category: `gem` commands (other) Group: None Status: Open Resolution: None Priority: 3 Submitted By: Roger Pack (rogerdpack) Assigned to: Ryan Davis (zenspider) Summary: gem rdoc uses some deprecated methods Initial Comment: running $ gem rdoc flickraw with 1.8.1 shows lots of deprecation warnings, which was a bit unexpected. Cheers! ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-06-07 16:50 Message: Hi! Believe it or not, we're moving to github's issue tracker! The pressure to move has been loud and clear, but for the longest time it didn't support the way we worked. Now that it has freeform labels it can support our workflow adequately. There is just one problem: Your bug is here and we don't want to lose you! What we'd like you to do is fairly painless and should only take a few minutes: Please file the _exact_ same ticket on github and provide a link back to this crufty old ticket so we can refer to any previous discussion that occurred. Once the new ticket is made, put a forwarding link to it here and close this ticket out. In a couple weeks, we'll track down the old tickets that are still open and decide what to do with them. We could have done this fairly automatically, but we really want you to do it so you're attached to the ticket and we can still communicate with you and keep a record of it. https://github.com/rubygems/rubygems/issues Thanks, The RubyGems Team ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29198&group_id=126 From noreply at rubyforge.org Tue Jun 7 19:50:09 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 7 Jun 2011 19:50:09 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29253 ] Gem plugins + gem install -i causes activation errors Message-ID: <20110607235011.B7EFE3C807E@rubyforge.org> Bugs item #29253, was opened at 2011-06-04 13:34 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29253&group_id=126 Category: `gem install` command Group: v1.8.x Status: Open Resolution: None Priority: 3 Submitted By: Eric Hodel (drbrain) Assigned to: Nobody (None) Summary: Gem plugins + gem install -i causes activation errors Initial Comment: Steps to reproduce: gem install rubygems-test (has a rake dependency) gem install rake -v 0.8.7 gem install rake gem install -i /tmp/gems rake Expected results: rake installed in /tmp/gems Actual results: ./lib/rubygems/dependency.rb:252:in `to_specs': Could not find rake (>= 0.8.7) amongst [] (Gem::LoadError) from ./lib/rubygems/specification.rb:760:in `find_in_unresolved' from ./lib/rubygems/specification.rb:760:in `map' from ./lib/rubygems/specification.rb:760:in `find_in_unresolved' from ./lib/rubygems/custom_require.rb:43:in `require' from ./lib/rubygems/remote_fetcher.rb:63:in `initialize' from ./lib/rubygems/remote_fetcher.rb:48:in `new' from ./lib/rubygems/remote_fetcher.rb:48:in `fetcher' from ./lib/rubygems/spec_fetcher.rb:66:in `initialize' from ./lib/rubygems/spec_fetcher.rb:43:in `new' from ./lib/rubygems/spec_fetcher.rb:43:in `fetcher' from ./lib/rubygems/dependency_installer.rb:129:in `find_gems_with_sources' from ./lib/rubygems/dependency_installer.rb:269:in `find_spec_by_name_and_version' from ./lib/rubygems/dependency_installer.rb:300:in `install' from ./lib/rubygems/commands/install_command.rb:124:in `execute' from ./lib/rubygems/commands/install_command.rb:118:in `each' from ./lib/rubygems/commands/install_command.rb:118:in `execute' from ./lib/rubygems/command.rb:278:in `invoke' from ./lib/rubygems/command_manager.rb:161:in `process_args' from ./lib/rubygems/command_manager.rb:120:in `run' from ./lib/rubygems/gem_runner.rb:64:in `run' from /usr/bin/gem:21 `gem install -i path` changes the source directory for Gem::Specification so no gems are available. This works with RubyGems 1.7.2 and older, probably due to separate Gem::SourceIndexes for installation of gems and for loading gems. A workaround is to uninstall rubygems-test or uninstall the old version of rake. A possible fix could be to force-resolve dependencies when changing Gem::Specification's source directories ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-06-07 16:50 Message: Hi! Believe it or not, we're moving to github's issue tracker! The pressure to move has been loud and clear, but for the longest time it didn't support the way we worked. Now that it has freeform labels it can support our workflow adequately. There is just one problem: Your bug is here and we don't want to lose you! What we'd like you to do is fairly painless and should only take a few minutes: Please file the _exact_ same ticket on github and provide a link back to this crufty old ticket so we can refer to any previous discussion that occurred. Once the new ticket is made, put a forwarding link to it here and close this ticket out. In a couple weeks, we'll track down the old tickets that are still open and decide what to do with them. We could have done this fairly automatically, but we really want you to do it so you're attached to the ticket and we can still communicate with you and keep a record of it. https://github.com/rubygems/rubygems/issues Thanks, The RubyGems Team ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29253&group_id=126 From noreply at rubyforge.org Tue Jun 7 19:50:09 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 7 Jun 2011 19:50:09 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29249 ] Can't downgrade to 1.37 from 1.8.5 Message-ID: <20110607235012.09F923C80A0@rubyforge.org> Bugs item #29249, was opened at 2011-06-03 11:15 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29249&group_id=126 Category: `gem install` command Group: None Status: Open Resolution: None Priority: 3 Submitted By: Luis Lavena (luislavena) Assigned to: Evan Phoenix (evan) Summary: Can't downgrade to 1.37 from 1.8.5 Initial Comment: User following the instructions form UPGRADING was not able to downgrade properly under Ruby 1.9.2: http://help.rubygems.org/discussions/problems/617-downgrading-rubygems-from-185-to-137-gives-an-error Find here a gist of the error: https://gist.github.com/1006834 Either the issue need to be corrected or the documentation needs to reflect the limitation. Thank you. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-06-07 16:50 Message: Hi! Believe it or not, we're moving to github's issue tracker! The pressure to move has been loud and clear, but for the longest time it didn't support the way we worked. Now that it has freeform labels it can support our workflow adequately. There is just one problem: Your bug is here and we don't want to lose you! What we'd like you to do is fairly painless and should only take a few minutes: Please file the _exact_ same ticket on github and provide a link back to this crufty old ticket so we can refer to any previous discussion that occurred. Once the new ticket is made, put a forwarding link to it here and close this ticket out. In a couple weeks, we'll track down the old tickets that are still open and decide what to do with them. We could have done this fairly automatically, but we really want you to do it so you're attached to the ticket and we can still communicate with you and keep a record of it. https://github.com/rubygems/rubygems/issues Thanks, The RubyGems Team ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29249&group_id=126 From noreply at rubyforge.org Tue Jun 7 19:50:10 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 7 Jun 2011 19:50:10 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29259 ] IO#tty? is not broken on Windows (MRI trunk) Message-ID: <20110607235011.EC1F93C809C@rubyforge.org> Bugs item #29259, was opened at 2011-06-07 03:07 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29259&group_id=126 Category: `gem` commands (other) Group: None Status: Open Resolution: Accepted Priority: 3 Submitted By: Usaku Nakamura (usa) Assigned to: Luis Lavena (luislavena) Summary: IO#tty? is not broken on Windows (MRI trunk) Initial Comment: see r31952 of MRI. RubyGems should check RUBY_VERSION >= "1.9.3", I think. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-06-07 16:50 Message: Hi! Believe it or not, we're moving to github's issue tracker! The pressure to move has been loud and clear, but for the longest time it didn't support the way we worked. Now that it has freeform labels it can support our workflow adequately. There is just one problem: Your bug is here and we don't want to lose you! What we'd like you to do is fairly painless and should only take a few minutes: Please file the _exact_ same ticket on github and provide a link back to this crufty old ticket so we can refer to any previous discussion that occurred. Once the new ticket is made, put a forwarding link to it here and close this ticket out. In a couple weeks, we'll track down the old tickets that are still open and decide what to do with them. We could have done this fairly automatically, but we really want you to do it so you're attached to the ticket and we can still communicate with you and keep a record of it. https://github.com/rubygems/rubygems/issues Thanks, The RubyGems Team ---------------------------------------------------------------------- Comment By: Luis Lavena (luislavena) Date: 2011-06-07 07:10 Message: Thank you Usa, will take a look and improve the code accordingly. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29259&group_id=126 From noreply at rubyforge.org Tue Jun 7 19:50:10 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 7 Jun 2011 19:50:10 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29258 ] GEM_HOME=xxx gem install rake installs doco wrong Message-ID: <20110607235013.28B263C809D@rubyforge.org> Bugs item #29258, was opened at 2011-06-06 16:10 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29258&group_id=126 Category: `gem install` command Group: None Status: Open Resolution: None Priority: 3 Submitted By: Ryan Davis (zenspider) Assigned to: Eric Hodel (drbrain) Summary: GEM_HOME=xxx gem install rake installs doco wrong Initial Comment: % l xxx/gems/rake-0.8.7/xxx/doc/rake-0.8.7/ total 0 0 rdoc/ 0 ri/ ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-06-07 16:50 Message: Hi! Believe it or not, we're moving to github's issue tracker! The pressure to move has been loud and clear, but for the longest time it didn't support the way we worked. Now that it has freeform labels it can support our workflow adequately. There is just one problem: Your bug is here and we don't want to lose you! What we'd like you to do is fairly painless and should only take a few minutes: Please file the _exact_ same ticket on github and provide a link back to this crufty old ticket so we can refer to any previous discussion that occurred. Once the new ticket is made, put a forwarding link to it here and close this ticket out. In a couple weeks, we'll track down the old tickets that are still open and decide what to do with them. We could have done this fairly automatically, but we really want you to do it so you're attached to the ticket and we can still communicate with you and keep a record of it. https://github.com/rubygems/rubygems/issues Thanks, The RubyGems Team ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29258&group_id=126 From noreply at rubyforge.org Tue Jun 7 19:50:10 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 7 Jun 2011 19:50:10 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29257 ] Massively Duplicated Deprecation Warnings Message-ID: <20110607235013.094B63C80A1@rubyforge.org> Bugs item #29257, was opened at 2011-06-06 13:27 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29257&group_id=126 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Scott Tadman (tadman) Assigned to: Nobody (None) Summary: Massively Duplicated Deprecation Warnings Initial Comment: I've added a pull request that tries to address some of the issues bundler has with deprecated functions: https://github.com/rubygems/rubygems/pull/70 This simply tracks which deprecations have been fired and doesn't trigger warnings for the same source line + method combination. The 1.8.5 version will report on deprecations an infinite number of times, something that nearly happens when some things are exercised inside a loop. Gem::SourceIndex#add_specs calls Gem::SourceIndex#add_spec many, many times, and both methods are deprecated. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-06-07 16:50 Message: Hi! Believe it or not, we're moving to github's issue tracker! The pressure to move has been loud and clear, but for the longest time it didn't support the way we worked. Now that it has freeform labels it can support our workflow adequately. There is just one problem: Your bug is here and we don't want to lose you! What we'd like you to do is fairly painless and should only take a few minutes: Please file the _exact_ same ticket on github and provide a link back to this crufty old ticket so we can refer to any previous discussion that occurred. Once the new ticket is made, put a forwarding link to it here and close this ticket out. In a couple weeks, we'll track down the old tickets that are still open and decide what to do with them. We could have done this fairly automatically, but we really want you to do it so you're attached to the ticket and we can still communicate with you and keep a record of it. https://github.com/rubygems/rubygems/issues Thanks, The RubyGems Team ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29257&group_id=126 From noreply at rubyforge.org Tue Jun 7 20:02:24 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 7 Jun 2011 20:02:24 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-28726 ] gem install --user-install as root adds cached .gem file outside of HOME Message-ID: <20110608000224.AC85518583B8@rubyforge.org> Bugs item #28726, was opened at 2010-11-16 12:43 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28726&group_id=126 Category: None Group: None >Status: Closed Resolution: None Priority: 3 Submitted By: Jeremy Evans (jeremyevans) Assigned to: Ryan Davis (zenspider) Summary: gem install --user-install as root adds cached .gem file outside of HOME Initial Comment: I think the problem is at https://github.com/rubygems/rubygems/blob/master/lib/rubygems/remote_fetcher.rb#L80 Basically, in RemoteFetcher#download, it's checking whether the install_dir (Gem.dir by default) is writable, and if so, it uses that dir. However, if the user is using the --user-install option, even if the user is root, it should not be writing outside of HOME/.gem. Basically, if the --user-install option is given, it should always download to HOME/.gem. This may require an API change. This affects building OpenBSD ports for some gems, since the --user-install option is used (in combination with a fake HOME). Usually, building is done as a regular user and is fine. However, if the builder is root, rubygems adds the .gem files to the /usr/local/lib/ruby directory when the gem is installed to HOME/.gem. Then when the package builder goes to install the package, the cached .gem file already exists and the package install fails. This isn't a critical bug, as it can be trivially worked around by specifying GEM_HOME=$HOME/.gem in the environment when using gem install --user-install (which the OpenBSD ports system now does). ---------------------------------------------------------------------- >Comment By: Jeremy Evans (jeremyevans) Date: 2011-06-07 17:02 Message: GitHub Issue #71: https://github.com/rubygems/rubygems/issues/71 ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-06-07 16:50 Message: Hi! Believe it or not, we're moving to github's issue tracker! The pressure to move has been loud and clear, but for the longest time it didn't support the way we worked. Now that it has freeform labels it can support our workflow adequately. There is just one problem: Your bug is here and we don't want to lose you! What we'd like you to do is fairly painless and should only take a few minutes: Please file the _exact_ same ticket on github and provide a link back to this crufty old ticket so we can refer to any previous discussion that occurred. Once the new ticket is made, put a forwarding link to it here and close this ticket out. In a couple weeks, we'll track down the old tickets that are still open and decide what to do with them. We could have done this fairly automatically, but we really want you to do it so you're attached to the ticket and we can still communicate with you and keep a record of it. https://github.com/rubygems/rubygems/issues Thanks, The RubyGems Team ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28726&group_id=126 From noreply at rubyforge.org Tue Jun 7 20:08:48 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 7 Jun 2011 20:08:48 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29116 ] Mega slowness in custom require Message-ID: <20110608000849.0807B3C809A@rubyforge.org> Bugs item #29116, was opened at 2011-04-05 18:01 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29116&group_id=126 Category: #gem and #require methods Group: None >Status: Closed Resolution: None Priority: 3 Submitted By: Sam Goldstein (samgoldstein) Assigned to: Ryan Davis (zenspider) Summary: Mega slowness in custom require Initial Comment: I recently upgraded to rubygems 1.6.5 and started experiencing a major slowdown loading the environment for a Rails 2.3 application. I traced the problem back to the Kernel.require (custom_require.rb) and Gem.loaded_path?. It seems that searching $LOADED_FEATURES repeatedly is inefficient and results in a 4x slowdown in my specific case. I've downgraded to rubygems 1.3.5 which doesn't suffer from this problem. This is a major hurdle to developing in ruby, as it takes me ~45 seconds to load the environment and run one test. Below is some console output demonstrating the problem. /www/aboutus/app_root [master] $ time rake environment (in /www/aboutus/app_root) real 0m11.407s user 0m8.787s sys 0m2.552s /www/aboutus/app_root [master] $ sudo gem update --system Updating RubyGems Updating rubygems-update Successfully installed rubygems-update-1.7.1 Updating RubyGems to 1.7.1 Installing RubyGems 1.7.1 RubyGems 1.7.1 installed === 1.7.1 / 2011-03-32 * 1 bug fix: * Fixed missing file in Manifest.txt. (Also a bug in hoe was fixed where `rake check_manifest` showing a diff would not exit with an error.) ------------------------------------------------------------------------------ RubyGems installed the following executables: /usr/local/bin/gem /www/aboutus/app_root [master] $ time rake environment (in /www/aboutus/app_root) NOTE: SourceIndex.new(hash) is deprecated; From /www/aboutus/app_root/config/../vendor/rails/railties/lib/rails/vendor_gem_source_index.rb:100:in `new'. real 0m46.707s user 0m41.200s sys 0m5.394s Thanks! ---------------------------------------------------------------------- >Comment By: Sam Goldstein (samgoldstein) Date: 2011-06-08 00:08 Message: This ticket is migrated to github issue #73 https://github.com/rubygems/rubygems/issues/73 ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-06-07 23:50 Message: Hi! Believe it or not, we're moving to github's issue tracker! The pressure to move has been loud and clear, but for the longest time it didn't support the way we worked. Now that it has freeform labels it can support our workflow adequately. There is just one problem: Your bug is here and we don't want to lose you! What we'd like you to do is fairly painless and should only take a few minutes: Please file the _exact_ same ticket on github and provide a link back to this crufty old ticket so we can refer to any previous discussion that occurred. Once the new ticket is made, put a forwarding link to it here and close this ticket out. In a couple weeks, we'll track down the old tickets that are still open and decide what to do with them. We could have done this fairly automatically, but we really want you to do it so you're attached to the ticket and we can still communicate with you and keep a record of it. https://github.com/rubygems/rubygems/issues Thanks, The RubyGems Team ---------------------------------------------------------------------- Comment By: Dan Peterson (dpiddy) Date: 2011-06-01 12:31 Message: Here's what my test case looks like with 1.5.2, 1.8.5 and master after Evan's change: # 1.5.2 eye help 1.26s user 0.26s system 99% cpu 1.526 total # 1.8.5 eye help 9.85s user 0.61s system 100% cpu 10.455 total # master eye help 5.44s user 0.51s system 100% cpu 5.947 total ---------------------------------------------------------------------- Comment By: Evan Phoenix (evan) Date: 2011-06-01 06:53 Message: I've moved the regexp creation outside the find block. Could someone who's seeing the issue report back how much of a difference it made? ---------------------------------------------------------------------- Comment By: Nick Rogers (tsp435cds) Date: 2011-05-30 21:47 Message: I am experiencing the same problem with my rails 2.3.11 application, recently upgraded from rubygems 1.3.7 to 1.7.2. Time to initialize rails is an abysmal average of 30s instead of 5s, and I use only a handful of gems. ~/rxg/console: rake gems (in /Users/nick/rxg/console) - [F] attr_encrypted - [F] eigenclass >= 1.1.1 - [F] encryptor >= 1.1.0 - [F] mocha >= 0.9.8 - [R] rake - [F] log4r - [F] netaddr - [F] ntp - [F] hoe >= 1.2.0 - [F] rubyforge >= 2.0.4 - [R] json_pure >= 1.1.7 - [R] rake >= 0.8.7 - [F] SystemTimer - [F] rack - [F] savon - [F] builder >= 2.1.2 - [F] crack >= 0.1.4 - [F] surpass I = Installed F = Frozen R = Framework (loaded before rails starts) ~/rxg/console: I concur that the problem is with custom_require, specifically Gem#loaded_path? and possibly elsewhere. Glancing at rubygems.rb, there are a number of careless instances of what should be loop invariant variables being re-computed within a loop. For example, the following change yielded a 50% performance increase to my rails app load time, however it was still not as good as under rubygems 1.3.7. *** rubygems-1.7.2-original/lib/rubygems.rb 2011-04-05 16:59:14.000000000 -0400 --- rubygems-1.7.2/lib/rubygems.rb 2011-05-30 17:20:56.000000000 -0400 *************** *** 1086,1093 **** def self.loaded_path? path # TODO: ruby needs a feature to let us query what's loaded in 1.8 and 1.9 $LOADED_FEATURES.find { |s| ! s =~ /(^|\/)#{Regexp.escape path}#{Regexp.union(*Gem.suffixes)}$/ } end --- 1086,1095 ---- def self.loaded_path? path # TODO: ruby needs a feature to let us query what's loaded in 1.8 and 1.9 + escaped_path = Regexp.escape(path) + union_suffixes = Regexp.union(*Gem.suffixes) $LOADED_FEATURES.find { |s| ! s =~ /(^|\/)#{escaped_path}#{union_suffixes}$/ } end ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-05-24 00:32 Message: More data, this time with a bit more cleanup and working against rails 2.3.12 (coming RSN) so that deprecations are cleaned up: repo=before-clean repo=after-clean number of gems: 280 number of gems: 175 1.3.7 real 0m2.113s real 0m1.901s user 0m1.762s user 0m1.582s sys 0m0.339s sys 0m0.314s 1.7.2 real 0m7.269s real 0m1.639s user 0m6.836s user 0m1.405s sys 0m0.417s sys 0m0.222s 1.8.2 real 0m7.947s real 0m1.920s user 0m7.488s user 0m1.680s sys 0m0.413s sys 0m0.228s Kinda scary how much those 105 gems affect stuff. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-05-23 23:47 Message: Much of this slowdown occurred as a result of us fixing complex gem dependency resolution bugs. Unfortunately, we're not in a good place to do too much to address this issue right now. I will point out that in both old (< 1.4) rubygems and newer, that the time is going to be proportional to the amount of gems installed. Keeping around a bunch of old stuff you're not using will only harm you in any version. I did get a repro using MOST of what Sam reported. I couldn't install some gems because I didn't have requisite libraries (eg I never use mysql, so it couldn't build) and some of his gems are not in the main gem repo. Of his 287 gems (WOW!) I was able to install 273 of them. Until I tried out a rails app, EVERY timing I tried to do wound up at least 25% faster in 1.7/1.8 over 1.3.7. Once we got to really complex graphs of activation (read: rails), I was able to get a repro where 1.7/1.8 was slower. I got the following times while loading a rails 2.3.4 config/environment.rb file: repo=xxx; before 'gem clean' number of gems: 273 1.3.7 real 0m1.492s user 0m1.230s sys 0m0.256s 1.7.2 real 0m3.533s user 0m3.281s sys 0m0.242s 1.8.2 real 0m3.998s user 0m3.731s sys 0m0.261s I copied that repo and ran gem clean on it (and reinstalled rails 2.3.4 because rails 3 wiped it out on cleanup!) and got the following MUCH better times: repo=yyy; after 'gem clean' number of gems: 183 1.3.7 real 0m1.288s user 0m1.054s sys 0m0.231s 1.7.2 real 0m1.106s user 0m0.932s sys 0m0.169s 1.8.2 real 0m1.365s user 0m1.181s sys 0m0.179s So... that's the workaround for now. I'll do what I can to profile and optimize, but I can't promise much for the next release, partially because we don't have enough test coverage on this aspect of rubygems. ---------------------------------------------------------------------- Comment By: Dan Peterson (dpiddy) Date: 2011-05-23 15:20 Message: This is still happening in 1.8.3. ---------------------------------------------------------------------- Comment By: Dan Peterson (dpiddy) Date: 2011-05-05 01:42 Message: I have seen this as well for something non-Rails. Using `rvm rubygems` I saw the slowness started with 1.6.0. Haven't had a chance to really dig into it more yet. ---------------------------------------------------------------------- Comment By: Sam Goldstein (samgoldstein) Date: 2011-04-05 18:07 Message: More info on gem dependencies and installed gems. $ rake gems (in /www/aboutus/compostus/compost) - [F] thrift_client ~> 0.4.3 - [I] thrift - [I] thrift = 0.2.0.4 - [F] simple_uuid = 0.1.1 - [F] cassandra = 0.8.2 - [F] thrift_client >= 0.4.0 - [I] thrift - [I] json - [R] rake - [F] simple_uuid >= 0.1.0 - [F] rack ~> 1.0.0 - [F] diff-lcs = 1.1.2 - [I] ffi ~> 0.6.0 - [R] rake >= 0.8.7 - [F] haml - [I] libxml-ruby - [I] hpricot >= 0.8.1 - [I] json - [I] mysql = 2.8.1 - [F] net-ssh - [F] ya2yaml = 0.26 - [F] ruby-openid = 2.1.6 - [F] mechanize = 1.0.0 - [I] nokogiri >= 1.2.1 - [I] nokogiri - [F] composite_primary_keys = 2.2.2 - [R] activerecord >= 2.2.0 - [F] aws-s3 = 0.6.2 - [F] xml-simple - [F] builder - [F] mime-types - [F] right_aws - [F] right_http_connection >= 1.2.4 - [F] fastercsv = 1.5.0 - [I] levenshtein - [F] newrelic_rpm = 2.13.4 - [F] after_commit ~> 1.0.7 - [R] activerecord - [F] less = 1.2.21 - [F] treetop >= 1.4.2 - [F] polyglot >= 0.3.1 - [F] mutter >= 0.4.2 - [F] treetop = 1.4.8 - [F] polyglot >= 0.3.1 - [F] mime-types = 1.16 - [I] curb = 0.7.8 I = Installed F = Frozen R = Framework (loaded before rails starts) $ gem list abstract (1.0.0) actionmailer (3.0.5, 3.0.3, 2.3.4, 2.2.2) actionpack (3.0.5, 3.0.3, 2.3.4, 2.2.2) activemodel (3.0.5, 3.0.3) activerecord (3.0.5, 3.0.3, 2.3.4, 2.2.2) activeresource (3.0.5, 3.0.3, 2.3.4, 2.2.2) activesupport (3.0.5, 3.0.3, 2.3.11, 2.3.8, 2.3.7, 2.3.5, 2.3.4, 2.2.2) acts_as_commentable (3.0.1, 2.0.2) addressable (2.2.4) after_commit (1.0.7, 1.0.5) amatch (0.2.3) amazon_sdb (0.6.7) amqp (0.6.0) ar-extensions (0.8.0) arel (2.0.9, 2.0.8) au_document_parser (0.5.3, 0.4.3, 0.4.2, 0.4.1, 0.4.0, 0.3.2, 0.3.1, 0.3.0, 0.2.4) autotest-growl (0.1.7) aws-s3 (0.6.2) babel (0.1.4) builder (2.1.2) bundler (1.0.10) capistrano (2.5.5) capybara (0.3.0) carmen (0.2.5) cassandra (0.7.2, 0.6) cgi_multipart_eof_fix (2.5.0) cheat (1.2.1) chronic (0.3.0, 0.2.3) clearance (0.10.3.2, 0.8.8, 0.8.3) compass (0.8.17) compass-960-plugin (0.9.11) composite_primary_keys (2.2.2) configuration (1.1.0) crack (0.1.4) cucumber (0.10.2, 0.6.3, 0.6.2) cucumber-rails (0.3.2, 0.2.4, 0.2.3) culerity (0.2.6) curb (0.7.8, 0.7.7.1, 0.7.1) daemons (1.0.10) database_cleaner (0.4.3) diesel (0.1.4) diff-lcs (1.1.2) differ (0.1.1) diffy (2.0.1) dirb (1.0.0, 0.1.1, 0.1.0) duration (0.1.0) erubis (2.6.6) eventmachine (0.12.10) factory_girl (1.2.3) fakefs (0.2.1) faker (0.3.1) faraday (0.5.7) fastercsv (1.5.0) fastthread (1.0.7) ffi (0.6.3, 0.5.4, 0.5.3) file-tail (1.0.4) fixjour (0.1.6) flexmock (0.8.6) gem_plugin (0.2.3) gemcutter (0.5.0) geminstaller (0.5.4) geokit (1.5.0) getopt-declare (1.28) gherkin (2.3.5) git (1.2.5) gltail (0.1.8) gravatar (1.0) grit (2.0.0, 1.1.1) haml (3.0.25, 3.0.13, 2.2.19, 2.2.9) heroku (1.9.8) highline (1.5.1) hoe (2.3.3) hpricot (0.8.1) httparty (0.5.0) i18n (0.5.0) icalendar (1.1.2, 1.1.0) jeweler (1.4.0) jm81-whois (0.5.0) json (1.4.6, 1.2.0, 1.1.6) json_pure (1.2.0) launchy (0.3.3) less (1.2.21) levenshtein (0.2.0) libxml-ruby (1.1.3) log4r (1.1.9) lorem (0.1.2) macaddr (1.0.0) mail (2.2.15, 1.5.2) maruku (0.6.0) mechanize (1.0.0, 0.9.3) memcache-client (1.7.4) micronaut (0.3.0) mime-types (1.16) mkrf (0.2.3) mocha (0.9.8) mongrel (1.1.5) more (0.1.1) multi_json (0.0.5) multipart-post (1.1.0) mutter (0.5.3) mysql (2.8.1) needle (1.3.0) net-scp (1.0.2) net-sftp (2.0.4, 1.1.0) net-ssh (2.0.15, 1.1.4, 1.0.10) net-ssh-gateway (1.0.1) newrelic_rpm (2.14.0, 2.9.9, 2.9.8, 2.9.3) nkallen-cache-money (0.2.5) nokogiri (1.4.0) open4 (1.0.1) paperclip (2.3.1.1) parseexcel (0.5.2) polyglot (0.3.1, 0.3.0, 0.2.9) rack (1.2.2, 1.2.1, 1.0.1) rack-mount (0.6.14, 0.6.13) rack-rewrite (1.0.2) rack-test (0.5.7, 0.5.3) rails (3.0.5, 3.0.3, 2.3.4, 2.2.2) railties (3.0.5, 3.0.3) rake (0.8.7, 0.8.3) rcov (0.9.6) RedCloth (4.2.2) redis (2.1.1) redis-namespace (0.10.0) resque (1.13.0) rest-client (1.4.2) riddle (1.0.11, 1.0.8) right_aws (1.10.0) right_http_connection (1.2.4) rpx_now (0.6.11) rspec (2.5.0, 1.3.0, 1.2.9, 1.2.7) rspec-core (2.5.1) rspec-expectations (2.5.0) rspec-mocks (2.5.0) rspec-rails (2.5.0, 1.3.2, 1.2.9, 1.2.7) ruby-aws (1.2.0) ruby-graphviz (0.9.21) ruby-ole (1.2.10.1) ruby-opengl (0.60.1) ruby-openid (2.1.6) ruby-prof (0.9.2, 0.8.1) rubyforge (2.0.4, 2.0.3) rubygems-update (1.7.1, 1.6.2) RubyInline (3.8.1) rufus-tokyo (0.1.14) rvm (0.0.98) selenium-webdriver (0.0.14) sequel (3.14.0, 3.9.0, 3.6.0) simple_uuid (0.0.2) sinatra (1.2.1, 1.1.2, 1.0, 0.9.5) slave (1.2.1) smurf (1.0.3) snailgun (1.0.6) spork (0.7.5) spreadsheet (0.6.4.1) sqlite3 (1.3.3) sqlite3-ruby (1.3.3, 1.2.5) stemmer (1.0.1) syntax (1.0.0) technicalpickles-jeweler (1.2.1) term-ansicolor (1.0.5, 1.0.4) Text (1.1.2) thinking-sphinx (1.3.18, 1.3.14) thor (0.14.6) thoughtbot-factory_girl (1.2.2) thrift (0.2.0.4) thrift_client (0.3.3, 0.3.1) tilt (1.2.2) timetrap (1.7.4, 1.4.0, 1.3.0, 1.2.1, 1.2.0, 1.1.3, 1.1.2) treetop (1.4.9, 1.4.8, 1.4.2) tzinfo (0.3.26, 0.3.25, 0.3.24) uuid (2.1.0, 2.0.1) uuidtools (2.1.2, 2.1.1) vegas (0.1.8) vlad (1.3.2) webrat (0.7.0, 0.6.0, 0.4.4) will_paginate (2.3.11) xhtmldiff (1.0.0) xml-simple (1.0.14, 1.0.12) xmpp4r (0.4) ya2yaml (0.26) ZenTest (4.1.4) ---------------------------------------------------------------------- Comment By: Sam Goldstein (samgoldstein) Date: 2011-04-05 18:02 Message: BTW the first environment load was with gem version 1.3.5 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29116&group_id=126 From ryand-ruby at zenspider.com Tue Jun 7 20:11:34 2011 From: ryand-ruby at zenspider.com (Ryan Davis) Date: Tue, 7 Jun 2011 17:11:34 -0700 Subject: [Rubygems-developers] moving to github issues Message-ID: <7268E5FA-B7B8-42AB-82B2-D9B6E1EEAB1F@zenspider.com> I just activated github issues for rubygems and added a bunch of labels to help us replicate the workflow from rubyforge's issue tracker (eg resolution, category, and status). I've added a canned message to the 3 trackers we had and mass blatted all open tickets to get the owners to migrate their tickets to github issues. As such... there be noise. From noreply at rubyforge.org Tue Jun 7 20:18:13 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 7 Jun 2011 20:18:13 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29259 ] IO#tty? is not broken on Windows (MRI trunk) Message-ID: <20110608001813.1B77F18583B8@rubyforge.org> Bugs item #29259, was opened at 2011-06-07 07:07 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29259&group_id=126 Category: `gem` commands (other) Group: None >Status: Closed Resolution: Accepted Priority: 3 Submitted By: Usaku Nakamura (usa) Assigned to: Luis Lavena (luislavena) Summary: IO#tty? is not broken on Windows (MRI trunk) Initial Comment: see r31952 of MRI. RubyGems should check RUBY_VERSION >= "1.9.3", I think. ---------------------------------------------------------------------- >Comment By: Luis Lavena (luislavena) Date: 2011-06-07 21:18 Message: Issue moved to GitHub: https://github.com/rubygems/rubygems/issues/75 ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-06-07 20:50 Message: Hi! Believe it or not, we're moving to github's issue tracker! The pressure to move has been loud and clear, but for the longest time it didn't support the way we worked. Now that it has freeform labels it can support our workflow adequately. There is just one problem: Your bug is here and we don't want to lose you! What we'd like you to do is fairly painless and should only take a few minutes: Please file the _exact_ same ticket on github and provide a link back to this crufty old ticket so we can refer to any previous discussion that occurred. Once the new ticket is made, put a forwarding link to it here and close this ticket out. In a couple weeks, we'll track down the old tickets that are still open and decide what to do with them. We could have done this fairly automatically, but we really want you to do it so you're attached to the ticket and we can still communicate with you and keep a record of it. https://github.com/rubygems/rubygems/issues Thanks, The RubyGems Team ---------------------------------------------------------------------- Comment By: Luis Lavena (luislavena) Date: 2011-06-07 11:10 Message: Thank you Usa, will take a look and improve the code accordingly. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29259&group_id=126 From luislavena at gmail.com Tue Jun 7 20:19:16 2011 From: luislavena at gmail.com (Luis Lavena) Date: Tue, 7 Jun 2011 20:19:16 -0400 Subject: [Rubygems-developers] moving to github issues In-Reply-To: <7268E5FA-B7B8-42AB-82B2-D9B6E1EEAB1F@zenspider.com> References: <7268E5FA-B7B8-42AB-82B2-D9B6E1EEAB1F@zenspider.com> Message-ID: On Tue, Jun 7, 2011 at 8:11 PM, Ryan Davis wrote: > I just activated github issues for rubygems and added a bunch of labels to help us replicate the workflow from rubyforge's issue tracker (eg resolution, category, and status). I've added a canned message to the 3 trackers we had and mass blatted all open tickets to get the owners to migrate their tickets to github issues. > > As such... there be noise. Understood and thank you. I just migrated one and I hope other bug reporters migrate it accordingly. Cheers, -- Luis Lavena AREA 17 - Perfection in design is achieved not when there is nothing more to add, but rather when there is nothing more to take away. Antoine de Saint-Exup?ry From drbrain at segment7.net Tue Jun 7 20:23:10 2011 From: drbrain at segment7.net (Eric Hodel) Date: Tue, 7 Jun 2011 17:23:10 -0700 Subject: [Rubygems-developers] Documentation generation has changed Message-ID: Gem::DocManager is still present but is no longer required nor used by RubyGems. Gem::RDoc replaces Gem::DocManager and uses a new hook to generate documentation (Gem.done_installing). The functionality of Gem::RDoc will be moving to a future version of rdoc. The file rubygems/rdoc.rb will continue to exist to facilitate loading of the proper code. Additionally, --no-rdoc and --no-ri are now deprecated: $ gem help install [?] Deprecated Options: --[no-]rdoc Generate RDoc for installed gems Use --document instead --[no-]ri Generate ri data for installed gems. Use --document instead [?] Replacing these is --document which accepts a comma separated list of documentation types to generate. `gem install rake --doc=rdoc` will generate only RDoc. `gem install rake --doc=rdoc,ri` is the default. `gem install rake --no-doc` will generate no documentation. Gem::RDoc uses a new done_installing hook to generate documentation which is called with a Gem::DependencyInstaller instance and a list of Gem::Specifications that have been installed. Additionally the documentation types are available through the installer instance passed to the done_installing hook: Gem.done_installing do |installer, specs| if installer.document.include? 'pretend' then puts "Pretending to document: #{specs.map { |spec| spec.full_name }}" end end From luislavena at gmail.com Tue Jun 7 20:41:54 2011 From: luislavena at gmail.com (Luis Lavena) Date: Tue, 7 Jun 2011 20:41:54 -0400 Subject: [Rubygems-developers] RbConfig.datadir deprecation and Gem.datadir TODO comment Message-ID: Hello, A particular project I'm working on need to compile and store certain files. Since these files are very version specific of the gem, I thought about using datadir. But, using RbConfig.datadir produces the following warning: irb(main):003:0> RbConfig.datadir("exerb") rbconfig/datadir.rb and {Rb}Config.datadir is being deprecated from RubyGems. It will be removed completely on or after June 2011. If you wish to rely on a datadir, please use Gem.datadir. => "C:/Users/Luis/Tools/Ruby/ruby-1.8.7-p334-i386-mingw32/share/exerb" And the path to "share" inside the installation of Ruby. However, usage of Gem.datadir produces something different: irb(main):005:0> gem "exerb" irb(main):005:0> Gem.datadir("exerb") => "C:/Users/Luis/.gem/ruby/x86-mingw32/1.8/gems/exerb-5.0.0-x86-mingw32/data/exerb" And I'm kinda confused... why the double directory? (exerb-version and again data/exerb)? Saying that just "data" seems enough to me. Then, seeing a comment on this line: https://github.com/rubygems/rubygems/blob/master/lib/rubygems.rb#L380 # TODO: deprecate Is not very inspiring... Is this required? anyone else using this that can provide further comments? 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 lsegal at soen.ca Tue Jun 7 22:41:46 2011 From: lsegal at soen.ca (Loren Segal) Date: Tue, 07 Jun 2011 22:41:46 -0400 Subject: [Rubygems-developers] Documentation generation has changed In-Reply-To: References: Message-ID: <4DEEE16A.30305@soen.ca> Hi Eric, On 6/7/2011 8:23 PM, Eric Hodel wrote: > Additionally the documentation types are available through the installer instance passed to the done_installing hook: > > Gem.done_installing do |installer, specs| > if installer.document.include? 'pretend' then > puts "Pretending to document: #{specs.map { |spec| spec.full_name }}" > end > end I take it that other documentation tools are expected to build plugins in this fashion that perform the appropriate documentation generation. However, In the case of static generation of HTML, it usually only makes sense to have one tool run-- so is there a way for the plugin to cancel the builtin rdoc hooks from running in this case? If so, what would be the recommended way? If not, can such a method be added? - Loren From noreply at rubyforge.org Wed Jun 8 06:25:38 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 8 Jun 2011 06:25:38 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-28286 ] Removal of wrappers should occur *after* successful uninstallation Message-ID: <20110608102538.298CE185834E@rubyforge.org> Bugs item #28286, was opened at 2010-06-09 13:11 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28286&group_id=126 Category: None Group: None >Status: Closed Resolution: Accepted Priority: 3 Submitted By: Sakuro OZAWA (sakuro) Assigned to: Ryan Davis (zenspider) Summary: Removal of wrappers should occur *after* successful uninstallation Initial Comment: When one terminates uninstallation of a gem, he/she would expect wrapper scripts remain. $ ruby --version ruby 1.9.3dev (2010-06-08 trunk 28202) [i386-darwin9.8.0] $ gem --version 1.3.7 $ gem uninstall nokogiri Remove executables: nokogiri in addition to the gem? [Yn] y Removing nokogiri You have requested to uninstall the gem: nokogiri-1.4.2 cucumber-0.8.0 depends on [nokogiri (>= 1.4.2)] mime-types-1.16 depends on [nokogiri (~> 1.2)] webrat-0.7.1 depends on [nokogiri (>= 1.2.0)] If you remove this gems, one or more dependencies will not be met. Continue with Uninstall? [Yn] n ERROR: While executing gem ... (Gem::DependencyRemovalException) Uninstallation aborted due to dependent gem(s) $ which nokogiri nokogiri not found ---------------------------------------------------------------------- >Comment By: Sakuro OZAWA (sakuro) Date: 2011-06-08 19:25 Message: Appears to be resolved in github issue #35. ( https://github.com/rubygems/rubygems/pull/35 ) ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-06-08 08:50 Message: Hi! Believe it or not, we're moving to github's issue tracker! The pressure to move has been loud and clear, but for the longest time it didn't support the way we worked. Now that it has freeform labels it can support our workflow adequately. There is just one problem: Your bug is here and we don't want to lose you! What we'd like you to do is fairly painless and should only take a few minutes: Please file the _exact_ same ticket on github and provide a link back to this crufty old ticket so we can refer to any previous discussion that occurred. Once the new ticket is made, put a forwarding link to it here and close this ticket out. In a couple weeks, we'll track down the old tickets that are still open and decide what to do with them. We could have done this fairly automatically, but we really want you to do it so you're attached to the ticket and we can still communicate with you and keep a record of it. https://github.com/rubygems/rubygems/issues Thanks, The RubyGems Team ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28286&group_id=126 From noreply at rubyforge.org Wed Jun 8 14:42:52 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 8 Jun 2011 14:42:52 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29176 ] Scary warnings are scaring helpless developers who can't do a thing about it Message-ID: <20110608184252.AA1793C807F@rubyforge.org> Bugs item #29176, was opened at 2011-05-06 13:07 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29176&group_id=126 Category: `gem` commands (other) Group: None Status: Open Resolution: None Priority: 3 Submitted By: Alex Chaffee (alexch) Assigned to: Ryan Davis (zenspider) Summary: Scary warnings are scaring helpless developers who can't do a thing about it Initial Comment: Suddenly anyone using "gem" is seeing many repetitions of lines like this: NOTE: Gem::Specification#default_executable= is deprecated with no replacement. It will be removed on or after 2011-10-01. Gem::Specification#default_executable= called from /Users/chaffee/.rvm/gems/ruby-1.9.2-p0/specifications/thin-1.2.7.gemspec:10. Many of my students are completely freaking out since something that's supposed to just work -- e.g. "gem install rails" or "gem list"-- is now spewing a huge amount of scary noise about things which are currently working just fine, and which they have no ability to affect. Even developers with the acumen to be able to read, understand, and react to these messages are wasting time googling, often fruitlessly, since even if they find Ryan's blog post, and run "gem pristine --all --no-extensions", it doesn't make all the warnings disappear. Here's my suggested fix, in three independent parts. 1. Stop repeating the same message again and again; instead set a global flag (already_scared_user?) and STFU if it happens for a different gem 2. Put the advice about running "gem pristine --all --no-extensions" in the error message instead of forcing people to google to find a workaround 3. Before the warning, try to rewrite the offending gemfile yourself, as if the user had run "gem pristine". If the rewrite fails, only then scare the user. And please remember that the "gem" command is the user interface to the entire world of Ruby development, for people of all experience levels. You have a responsibility not to scare off our friends, new and old. ---------------------------------------------------------------------- >Comment By: Alex Chaffee (alexch) Date: 2011-06-08 11:42 Message: Moved to https://github.com/rubygems/rubygems/issues/84 ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-06-07 16:50 Message: Hi! Believe it or not, we're moving to github's issue tracker! The pressure to move has been loud and clear, but for the longest time it didn't support the way we worked. Now that it has freeform labels it can support our workflow adequately. There is just one problem: Your bug is here and we don't want to lose you! What we'd like you to do is fairly painless and should only take a few minutes: Please file the _exact_ same ticket on github and provide a link back to this crufty old ticket so we can refer to any previous discussion that occurred. Once the new ticket is made, put a forwarding link to it here and close this ticket out. In a couple weeks, we'll track down the old tickets that are still open and decide what to do with them. We could have done this fairly automatically, but we really want you to do it so you're attached to the ticket and we can still communicate with you and keep a record of it. https://github.com/rubygems/rubygems/issues Thanks, The RubyGems Team ---------------------------------------------------------------------- Comment By: Chad Woolley (thewoolleyman) Date: 2011-06-02 08:50 Message: https://github.com/rubygems/rubygems/pull/66#issuecomment-1281426 ---------------------------------------------------------------------- Comment By: William Denniss (divzero) Date: 2011-05-25 04:23 Message: +1 that it would be good to reduce the 'scaryness'/volume of these warnings. I was setting up rails on a new machine for a colleague today. He saw all the errors and assumed the install was broken until I assured him it wasn't. I think it's good to have deprecation warnings ??but having so many, and for something that that needs to be fixed by the gem maintainers and not end-user-developers, doesn't seem to help. We were all 'helpless developers' once don't forget! Pull request #59 seems to fit the bill. ---------------------------------------------------------------------- Comment By: Chad Woolley (thewoolleyman) Date: 2011-05-24 17:05 Message: We are now getting duplicate pull requests in addition to Alex's (https://github.com/rubygems/rubygems/pull/66#issuecomment-1232323). May we please have the active maintainers weigh in on whether or not Alex's pull request can or cannot be merged? We can probably arrange to discuss on IRC if that is necessary... ---------------------------------------------------------------------- Comment By: Chad Woolley (thewoolleyman) Date: 2011-05-22 16:38 Message: Is there any reason not to merge Alex's patch? https://github.com/rubygems/rubygems/pull/59 He stepped up and wrote some code to make the situation better, and had it code-reviewed by Evan. Can we at least merge that or give feedback? ---------------------------------------------------------------------- Comment By: Jordan Sissel (jordansissel) Date: 2011-05-22 14:06 Message: I suspect this ticket not going to be resolved and is falling on deaf ears the ratio of "suck it up" responses to the "this sucks, please help" comments. If this is thie case, please just close this ticket with a resolution of whatever rubyforge's equivalent of "won't fix" with relevant links to workarounds. ---------------------------------------------------------------------- Comment By: Beoran Aegul (beoran) Date: 2011-05-22 01:10 Message: +1 for solution 1. Running gem pristine broke my rubygems, so I think it's a non-solution. I understand the need to clean up rubygems, but trying to force the whole ruby world to upgrade their gems specs so suddenly is not a good idea, IMHO. Not to mention many useful gems out there that are not maintained actively anymore. Kind Regards, B. ---------------------------------------------------------------------- Comment By: Alex Chaffee (alexch) Date: 2011-05-18 13:45 Message: Ping. My patch https://github.com/rubygems/rubygems/pull/59 doesn't change the inner workings at all, just improves the way deprecations are reported. Given that the idea is to get people to pay attention to them, it seems like people are more likely to pay attention to an organized list than a disorganized flood (especially since the list removes duplicates). Evan has code reviewed the patch and I implemented all his suggestions. ---------------------------------------------------------------------- Comment By: Luis Lavena (luislavena) Date: 2011-05-12 14:58 Message: Ryan, I think I did these steps before 1.8.2, I haven't tried it yet. Also since all my gems are fixed now, can't test again :-) ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-05-12 14:19 Message: Luis, unless I'm not understanding the rvm gem setup correctly, there is no need to do the `rvm use` line anymore. pristine had a bug with multiple repos that was fixed in 1.8.2. ---------------------------------------------------------------------- Comment By: Scott Tadman (tadman) Date: 2011-05-12 09:44 Message: Thanks, Luis, for that tip. I guess that means to upgrade rubygems the user is obligated to: rvmsudo bash gem pristine --all rvm use 1.9.2-p180 at global gem pristine --all Where this is documented other than this ticket, I have no idea. If I hadn't spent hours trying to remedy this, I would've just reverted to gem 1.6.0 and called it a day. If the intent of these warnings is to get people to upgrade, I have a feeling the opposite thing will occur. ---------------------------------------------------------------------- Comment By: Luis Lavena (luislavena) Date: 2011-05-12 08:22 Message: @Scott Tadman: gem pristine with "--no-extensions" will not fix gems that have extensions, that includes rcov, json, perftools. For that, you need "gem pristine" alone. As for rake, it is placed in the global namespace of RVM, so you need to switch to that namespace and correct it: rvm use 1.9.2-p180 at global gem pristine rake Then switch to your normal gemset. ---------------------------------------------------------------------- Comment By: Scott Tadman (tadman) Date: 2011-05-12 08:11 Message: Further investigation reveals that Jeweler's generated .gemspec file is affected by the version of rubygems installed, and that if building against a newer rubygems it will not put in the default_executable= call, so at least that much is fixed. However, the catch-22 here is that you need to build using a newer version of rubygems, which because of all the crazy warnings you get, I'm sure a lot of developers would avoid, instead reverting to an earlier, safer version. I have run gem pristine --all --no-extensions over six times on an OS X rvm-based Ruby 1.9.2 set of system gems and I'm still getting warnings. The first pass removed most, the second some, and the rest virtually none. I'm not sure why this needs to be run more than once in the first place, nor why this is the responsibility of the user. Now anything that even touches rubygems ends up getting lit up with warnings, the final few of which appear to be the most stubborn: NOTE: Gem::Specification#default_executable= is deprecated with no replacement. It will be removed on or after 2011-10-01. Gem::Specification#default_executable= called from /opt/local/rvm/gems/ruby-1.9.2-p180 at global/specifications/rake-0.8.7.gemspec:10. NOTE: Gem::Specification#default_executable= is deprecated with no replacement. It will be removed on or after 2011-10-01. Gem::Specification#default_executable= called from /opt/local/rvm/gems/ruby-1.9.2-p180/specifications/json-1.5.1.gemspec:10. NOTE: Gem::Specification#default_executable= is deprecated with no replacement. It will be removed on or after 2011-10-01. Gem::Specification#default_executable= called from /opt/local/rvm/gems/ruby-1.9.2-p180/specifications/perftools.rb-0.5.6.gemspec:10. NOTE: Gem::Specification#default_executable= is deprecated with no replacement. It will be removed on or after 2011-10-01. Gem::Specification#default_executable= called from /opt/local/rvm/gems/ruby-1.9.2-p180/specifications/rcov-0.9.9.gemspec:11. (in /Users/tadman/git/pigeon) It is worrying that the pristine operation not only produces ~500KB of warnings when processing its various things which buries any actual errors in the process. Maybe there's a reason why these gems can't be pristined properly, but it gets lost in the hurricane of warnings. ---------------------------------------------------------------------- Comment By: Mike Bethany (mikbe) Date: 2011-05-12 00:36 Message: The deprecation warnings made it virtually impossible to work. Every time autotest ran I would have a screen full of gobbledygook I had to sort through, very annoying. I wrote Chicken Little to disable the deprecation warnings just for the two major offenders. You can install the gem with: `gem install chicken_little` then run it `chicken_little install` You can also just go in and edit the RubyGems specification.rb file yourself and comment out those lines. Source: https://github.com/mikbe/chicken_little RubyGems: https://rubygems.org/gems/chicken_little P.S. RubyGems 1.8.2 seems to be broken in Ubuntu 10.10. Funny enough in the specification.rb file at line 277. Though it seems to be OK in OS X 10.6.7. ---------------------------------------------------------------------- Comment By: Alex Chaffee (alexch) Date: 2011-05-11 16:25 Message: I've gone ahead and made a patch. My fork of rubygems still prints out warnings, but after the first warning, it buffers up all remaining warnings and then emits them at_exit in a somewhat nicer report format, like this: Some of your installed gems called deprecated methods. See http://blog.zenspider.com/2011/05/rubygems-18-is-coming.html for background. Use 'gem pristine --all' to fix or 'rubygems update --system 1.7.2' to downgrade. TestDeprecate::Thing#foo is deprecated; use bar instead. It will be removed on or after 2099-03-01. called from /Users/chaffee/dev/rubygems/test/rubygems/test_deprecate.rb:174 called from /Users/chaffee/dev/rubygems/test/rubygems/test_deprecate.rb:175 called from /Users/chaffee/dev/rubygems/test/rubygems/test_deprecate.rb:177 TestDeprecate::Thing#goo is deprecated; use bar instead. It will be removed on or after 2099-04-01. called from /Users/chaffee/dev/rubygems/test/rubygems/test_deprecate.rb:176 I also pulled in the "--no-warnings" patch, but set the default back to "show all warnings" (i.e. skip=false). https://github.com/alexch/rubygems/commit/5572c2c1bb88e2e1b55b8d62 3fe4ef58a954c2a1 ---------------------------------------------------------------------- Comment By: Scott Tadman (tadman) Date: 2011-05-11 11:06 Message: Part of this problem is that Jeweler, a gem used by many authors to build their gems, inserts the default_executable= line in all the .gemspec files it produces. This is something done without the knowledge of the authors, and as one, I'm not even sure how to turn it off. I'll have to do more research. In the mean-time I need to live with the guilt and shame of causing warnings for everyone using anything I've made. I do want to keep up to date. I use Ruby 1.9.2 and the latest everything for new projects, but there are many legacy applications I'm involved with that for reasons of budget, dependency hell, or otherwise, are constrained to specific older versions. What I'm asking is why methods can't be deprecated by rendering them non-functional instead of causing things to explode by calling methods that no longer exist. It is common practice amongst UNIX shell utilities to have non-functional arguments for this very reason. I'm not saying to support the API, but at least make it mostly compatible with the newest spec even if it may not perform exactly as intended. For instance, most browsers don't support the tag, but they also don't refuse to render the page because of a lack of support. Once again, these are not my "decrepit needs", but rather the fact that there are hundreds if not thousands of gems out there with this mostly useless call to default_executable= as inserted by Jeweler and others that could be harmlessly ignored. I will post another ticket relating to the warnings later if I can replicate it. I have mostly fixed the issue using the pristine option which should be advertised more clearly or, better yet, done automatically when gem is updated to the newest release. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-05-11 02:02 Message: Scott, Please file a ticket with details and, if possible, reproduction steps showing that rolling back to 1.7.2 still has deprecation warnings that were added to 1.8.0. If it isn't too much to ask, please file a ticket with details and, if possible, reproduction steps showing "literally, 4000+ lines of warnings when running ordinary rake tasks" after running `gem pristine --all --no-extensions`. Do note that I suspect there is a bug in `gem pristine` in scenarios like using rvm w/ multiple gem directories... I don't have a repro for that yet. Finally, the majority of these deprecations are created _by_ rubygems in gemspecs and are fixable _by_ rubygems (pristine bugs notwithstanding)... Those warnings that are left afterwards represent real usage of methods that ARE going away. You state that you're intentionally running old gems on your apps but you insist on updating rubygems & bundler... You're going to update to a version that doesn't have the implementation one of your decrepit needs. What is your plan for that? Do you really think it reasonable that we should keep around API supporting everything all the way back to 2004? I'm sorry, but that just doesn't seem sane to me. We have to move on, even if you won't. ---------------------------------------------------------------------- Comment By: Scott Tadman (tadman) Date: 2011-05-10 21:37 Message: This issue is driving me berserk. I've pristined, I've rolled back to 1.7.2 like the Germans retreating from Russia and still I'm getting nagged and hassled. When something like default_executable is specified in default gemspec files that Jeweler produces and other templates that many have used to build out their gemspecs, it does seem like a bit of a nuisance. Maybe it's better to rescind support for it and turn it into a method that does nothing simply for compatibility reasons. Document the method as deprecated and non-functional for the curious. Lobby to get it removed from examples and places like Jeweler. I have applications with dozens of deliberately old versions of gems because the associated applications aren't up to date and upgrading causes problems. The one thing I do want to keep up to date is support utilities like gem and bundler, though, and getting, literally, 4000+ lines of warnings when running ordinary rake tasks is not helping. Even if I nagged and hassled every single gem builder, and seriously, I have nagged many about Ruby 1.9 issues, this still wouldn't matter because I simply have older versions of gems installed that cannot be patched without altering the space-time continuum. This is basically condemning me to using an antiquated version of gem so long as I have even one squeaky wheel in the whole system, as a single out of date gem will produce warnings for every gem related operation. When installing a new gem, if strictly necessary, it could say that the .gemspec is out of date and should be updated while hinting at the obscure pristine command as to how that might remedy it. I have wildly different versions of gem installed on my systems, but it's as if every time I go to update to the latest I get slapped in the face with something like this. I honestly wonder how other people have fared. After a lot of fussing about, experimenting with different approaches and attempting to be as unobtrusive as possible, I have come up with a patch that enables Deprecate.skip by default and also allows the setting to be toggled on or off as desired using the --warnings or --no-warnings options for install. After inspecting the implementation of this, which appears to have erupted into the root namespace as the module Deprecate, and without any sort of unit test, I have inverted the default because warnings are generated before command options are processed and there does not appear to be any other way. Patch: https://gist.github.com/965921 ---------------------------------------------------------------------- Comment By: Stephen Bannasch (stepheneb) Date: 2011-05-10 20:13 Message: For now I'm using this solution: gem update --system 1.7.2 Thanks Luis -- I didn't remember how easy it was to downgrade RubyGems. After running: gem pristine --all --no-extensions -- running a single spec test In my rails 2.3.11 project with RubyGems 1.8.1 generates 317 lines of warnings before I see the 10 lines of results: https://gist.github.com/965850 It's certainly annoying enough to get me to plan to fix my gem (jnlp) but my one gem is just a tiny bit of the noise in general. ---------------------------------------------------------------------- Comment By: Jordan Sissel (jordansissel) Date: 2011-05-10 18:36 Message: FWIW, I support deprecations, but these warning messages are going to users, not developers. And that sucks. For example, all my ruby nagios alerts are filled, now, with pointless warnings about libraries my code is *not* using. So many warnings, in fact, that the test code's output is lost. This warning should pop up when developers run 'gem build foo.gemspec' and no other time. Why? Consider a user who has code that relies on rake '0.8.0' explicitly. You can't actually fix 'rake 0.8.0' on rubygems.org because you can't overwrite an existing release (for good reason). So now, for eternity, this user is stuck with warning messages. ---------------------------------------------------------------------- Comment By: Alex Chaffee (alexch) Date: 2011-05-10 10:55 Message: Chad - A two-line warning per gem would still be super noisy. One compromise would be to queue up a list of offending gems per warning and then emit them all on_exit in a single line. As for patches, as I said before, I'd be happy to spend my time working on that, but not until I get the goahead from a member of the core team (especially considering that first comment). ---------------------------------------------------------------------- Comment By: Scott Tadman (tadman) Date: 2011-05-10 09:26 Message: I just "upgraded" gem and now I'm greeted with over a thousand lines of warnings, nearly one for every gem I have installed on my system. It doesn't just warn for gems I use, but any gems I might happen to have that are out of date. The message itself is meaningless as there's really nothing I can do about it, and further, it doesn't seem like ignoring that directive instead of complaining about it would have much of an effect on the end user. Since when is it the responsibility of gem users to hassle gem builders into compliance? Why can't the gem build operation give the builder a hard time instead? Why can't rubygems.org reject the gem out of protest? As a note, I'm also getting a kabillion identical warnings apparently from rubygems itself: Gem::SourceIndex#add_spec called from /opt/local/rvm/rubies/ree-1.8.7-2011.03/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:127. NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It will be removed on or after 2011-11-01. Gem::SourceIndex#add_spec called from /opt/local/rvm/rubies/ree-1.8.7-2011.03/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:127. NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It will be removed on or after 2011-11-01. Gem::SourceIndex#add_spec called from /opt/local/rvm/rubies/ree-1.8.7-2011.03/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:127. NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It will be removed on or after 2011-11-01. Gem::SourceIndex#add_spec called from /opt/local/rvm/rubies/ree-1.8.7-2011.03/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:127. NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It will be removed on or after 2011-11-01. Gem::SourceIndex#add_spec called from /opt/local/rvm/rubies/ree-1.8.7-2011.03/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:127. NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It will be removed on or after 2011-11-01. Gem::SourceIndex#add_spec called from /opt/local/rvm/rubies/ree-1.8.7-2011.03/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:127. NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It will be removed on or after 2011-11-01. Gem::SourceIndex#add_spec called from /opt/local/rvm/rubies/ree-1.8.7-2011.03/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:127. NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It will be removed on or after 2011-11-01. Gem::SourceIndex#add_spec called from /opt/local/rvm/rubies/ree-1.8.7-2011.03/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:127. NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It will be removed on or after 2011-11-01. ---------------------------------------------------------------------- Comment By: Chad Woolley (thewoolleyman) Date: 2011-05-08 11:43 Message: I agree, it would be nice if the deprecation warning were once per gem (NOT once for all gems as Alex suggested; that would defeat the purpose of getting people to complain to gem authors to fix their specs) However, I don't see any patches or even failing tests attached to this ticket yet... ---------------------------------------------------------------------- Comment By: Loren Segal (lsegal) Date: 2011-05-08 09:40 Message: Ryan, I'm not too sure if you read the entirety of my message. Just in case, I'll summarize again: 1. I agree that having warnings telling developers to update their APIs is good. I believe I said that. (Feel free to check) 2. The issue in this report is not about whether the warnings should exist or not, because everybody here agrees they should. The issue is how often they need to be printed. Given that I am suggesting the same fix as Alex, I don't see how this falls out of the scope of the ticket. 3. My feedback was not (entirely) a "me too". I am simply trying to provide extra information regarding the breadth of this issue that others might not be aware of; specifically that `gem pristine --all` is not a complete solution to this issue, at least it does not guarantee the hiding of all warning *spam* (remember, not arguing about first-time warnings, but complete page-spam). As far as I know, that problem was not yet discussed. I'm of the opinion that all relevant information should be provided with a bug report. There's no need to jump down users throats for providing extra information, so please try to use your indoor voice. 3. I don't see why modifying the warnings to show once (per method) needs to be controversial. It seems like quite a simple and reasonable change, at least to me. Is it not reasonable to you? Why not? Finally, as far as I know, open source relies on feedback from the community; certainly a tool that is widely used and part of Ruby's standard library deserves feedback from all of the community. Telling users that they are not allowed to voice their opinion on an open ticket simply does not compute. I'm therefore politely declining your invitation to "get off this ticket". Though, I suppose this should have prefaced the response with this note instead. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-05-08 01:56 Message: No worries. ---------------------------------------------------------------------- Comment By: Justin Collins (presidentbeef) Date: 2011-05-07 23:57 Message: Sorry, my mistake. I didn't notice that gem was called out specifically. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-05-07 23:54 Message: Justin, As described at http://blog.zenspider.com/2011/05/rubygems-18-is-coming.html and elsewhere, rake is one of those unfortunate gems that explicitly uses the deprecated API in their gemspec. Please file a bug on the rake bug tracker. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-05-07 23:53 Message: Loren, Get off this ticket. Everything you just described falls outside of the scope of this ticket. Specifically: "helpless developers". The point of having deprecations at all is to get those "hundreds" of libraries that use deprecated API to update their code. If you want to "me too", then yippie... but your hyperbole isn't a "me too" it is a completely separate issue (and one I will more readily reject). ---------------------------------------------------------------------- Comment By: Justin Collins (presidentbeef) Date: 2011-05-07 23:19 Message: I did a fresh install of 1.9.2 with rvm, then upgraded Ruby Gems. The only gem installed was "rake", and after running "gem pristine --all", "gem pristine --all --no-extensions", and "gem pristine rake", I still get the following error: NOTE: Gem::Specification#default_executable= is deprecated with no replacement. It will be removed on or after 2011-10-01. Gem::Specification#default_executable= called from /home/justin/.rvm/gems/ruby-1.9.2-p180 at global/specifications/rake-0.8.7.gemspec:10. ---------------------------------------------------------------------- Comment By: Loren Segal (lsegal) Date: 2011-05-07 22:40 Message: I have to agree with the severity of this issue. The problem is unfortunately not just limited to the `gem` binary. Any library making use of deprecated APIs will also get these warnings ad-infintum, so gem pristinie --all doesn't solve this issue, only small one part of it. For example, any gem that makes use of SourceIndex will see these deprecation warnings on each usage. There are currently hundreds of libraries that make use of this class, as per my latest search on codesearch: http://codesearch.google.com/codesearch?q=SourceIndex+lang:ruby and http://codesearch.google.com/codesearch?q=Gem.source_index+lang%3Aruby You might get lucky and just see a few of these warnings, but if the method is called within a loop, RubyGems will not be forgiving, and spam you many, many, times (see http://codesearch.google.com/codesearch/p?hl=en#L18QHnAzSFA/bin/minigem&q=Gem.source_index%20lang:ruby&sa=N&cd=46&ct=rc for just one random example). In some cases, this output may even render the lib/tool completely unusable, especially if it relies heavily on console output. Because of that possibility, an otherwise innocuous (and transitional) warning can become a "severe" compatibility bug. Just like Alex, I'm all for warnings, but I foresee a lot of developers scrambling to provide fixes for their users in the coming months, especially in the cases where their tools start scrolling pages of warnings just because of one method call. I'm not sure devs or users will be too happy about this. Fortunately the fix is simple, as Alex pointed pointed out. I think it would be sensible to add the suggested "already_scared_user?" flag; it can probably be done on a per method name granularity. Given that all of the deprecations are wrapped inside a Deprecation module AFAIK(?), this should be pretty simple to add. ---------------------------------------------------------------------- Comment By: Luis Lavena (luislavena) Date: 2011-05-06 15:04 Message: Which gem was not solved by gem pristine --all? please provide complete output, we can't help without the output. As for drowning on this issue: revert back to 1.7.2 There is no easy way to solve existing gem specifications without doing gem pristine --all And we can't help solve the others without people telling us which ones didn't get fixed for us to look at *why*. So, I know were are you coming from, heck, I work on Windows, what more weird scenario for failures could be than that? And even so, gem pristine --all solved all the issues. Help us help you. ---------------------------------------------------------------------- Comment By: Alex Chaffee (alexch) Date: 2011-05-06 14:41 Message: Luis - thanks, "gem pristine -all" has fixed most -- but still not quite all -- of the messages. Warnings are indeed good, but only until they become noise. That is extra bad since it can drown out other important information, especially for less experienced people who are mystified by everything coming down on the console. One reason I'm concerned about this is that tonight in two different cities we're doing a Railsbridge Ruby For Women Workshop Install Fest, and most of the students won't understand what's going on, and the volunteers may not either. This will add chaos to an already chaotic and frustrating session. Not your problem, I know, but I wanted you to know where I'm coming from. ---------------------------------------------------------------------- Comment By: Luis Lavena (luislavena) Date: 2011-05-06 13:38 Message: gem pristine --all --no-extensions will fix the gems that do not have extensions You need to do gem pristine -all, but that will not accept parameters for each gem. In my case I didn't require additional parameters to each gem so a simple gem pristine --all solved all the warnings. Warnings are good, and as always, you can rollback to previous versions if you find it doesn't work for you: gem update --system 1.7.2 ---------------------------------------------------------------------- Comment By: Alex Chaffee (alexch) Date: 2011-05-06 13:27 Message: I wasn't trying to be inflammatory. This is a real problem, wasting the real time of real people across the world. And I'd be happy to submit a patch but somehow it doesn't seem likely you'd accept it. ---------------------------------------------------------------------- Comment By: Erik Hollensbe (erikh) Date: 2011-05-06 13:22 Message: Really? Don't you have anything better to do than to post inflammatory shit to this tracker? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29176&group_id=126 From jon.forums at gmail.com Wed Jun 8 15:59:21 2011 From: jon.forums at gmail.com (Jon) Date: Wed, 8 Jun 2011 15:59:21 -0400 Subject: [Rubygems-developers] Documentation generation has changed In-Reply-To: References: Message-ID: <20110608155921.04050141.jon.forums@gmail.com> > Additionally, --no-rdoc and --no-ri are now deprecated: > ...SNIP... > Replacing these is --document which accepts a comma separated list of documentation types to generate. `gem install rake --doc=rdoc` will generate only RDoc. `gem install rake --doc=rdoc,ri` is the default. `gem install rake --no-doc` will generate no documentation. 1) Assuming these options will be removed in the future, when are you targeting removal? 2) What specifically will RG do when it sees a .gemrc containing: gem: --no-ri --no-rdoc 3) One can use --doc or --document interchangeably? Jon --- blog: http://jonforums.github.com/ twitter: @jonforums "Anyone who can only think of one way to spell a word obviously lacks imagination." - Mark Twain From ryand-ruby at zenspider.com Wed Jun 8 16:38:44 2011 From: ryand-ruby at zenspider.com (Ryan Davis) Date: Wed, 8 Jun 2011 13:38:44 -0700 Subject: [Rubygems-developers] Documentation generation has changed In-Reply-To: <20110608155921.04050141.jon.forums@gmail.com> References: <20110608155921.04050141.jon.forums@gmail.com> Message-ID: <8E3A99D8-63E6-4488-BEA1-6E95545F169C@zenspider.com> On Jun 8, 2011, at 12:59 , Jon wrote: >> Additionally, --no-rdoc and --no-ri are now deprecated: >> ...SNIP... >> Replacing these is --document which accepts a comma separated list of documentation types to generate. `gem install rake --doc=rdoc` will generate only RDoc. `gem install rake --doc=rdoc,ri` is the default. `gem install rake --no-doc` will generate no documentation. > > > 1) Assuming these options will be removed in the future, when are you targeting removal? > > 2) What specifically will RG do when it sees a .gemrc containing: > > gem: --no-ri --no-rdoc > > 3) One can use --doc or --document interchangeably? I can't answer 1 or 2, but 3 is easy.... OptionParser allows for unambiguous shortcuts so they're exactly the same thing. From ryand-ruby at zenspider.com Wed Jun 8 16:40:03 2011 From: ryand-ruby at zenspider.com (Ryan Davis) Date: Wed, 8 Jun 2011 13:40:03 -0700 Subject: [Rubygems-developers] github issues and the mailing list Message-ID: <2E2C993A-A050-443C-8AB3-5DD4E652EA11@zenspider.com> Even tho it means twice as much mail for me, I liked that the old system was subscribed and publishing ticket activity to the mailing list. More eyeballs == better. I don't know of a way to make that happen for github issues. Anyone know if it is possible? From drbrain at segment7.net Wed Jun 8 17:02:09 2011 From: drbrain at segment7.net (Eric Hodel) Date: Wed, 8 Jun 2011 14:02:09 -0700 Subject: [Rubygems-developers] Documentation generation has changed In-Reply-To: <20110608155921.04050141.jon.forums@gmail.com> References: <20110608155921.04050141.jon.forums@gmail.com> Message-ID: On Jun 8, 2011, at 12:59 PM, Jon wrote: >> Additionally, --no-rdoc and --no-ri are now deprecated: >> ...SNIP... >> Replacing these is --document which accepts a comma separated list of documentation types to generate. `gem install rake --doc=rdoc` will generate only RDoc. `gem install rake --doc=rdoc,ri` is the default. `gem install rake --no-doc` will generate no documentation. > > 1) Assuming these options will be removed in the future, when are you targeting removal? I'm not currently targetting any removal date. I've learned from rdoc that it is Very Hard to deprecate command line arguments. > 2) What specifically will RG do when it sees a .gemrc containing: > > gem: --no-ri --no-rdoc The same as it does now. These options now set options[:document] on the command instead of :generate_rdoc and :generate_ri. > 3) One can use --doc or --document interchangeably? You can use either as OptionParser allows the shortest unambiguous argument to be used much like `gem` allows the shortest unambiguous subcommand. (`gem install` and `gem i` both install gems.) From luislavena at gmail.com Wed Jun 8 18:19:15 2011 From: luislavena at gmail.com (Luis Lavena) Date: Wed, 8 Jun 2011 18:19:15 -0400 Subject: [Rubygems-developers] github issues and the mailing list In-Reply-To: <2E2C993A-A050-443C-8AB3-5DD4E652EA11@zenspider.com> References: <2E2C993A-A050-443C-8AB3-5DD4E652EA11@zenspider.com> Message-ID: On Wed, Jun 8, 2011 at 4:40 PM, Ryan Davis wrote: > Even tho it means twice as much mail for me, I liked that the old system was subscribed and publishing ticket activity to the mailing list. More eyeballs == better. I don't know of a way to make that happen for github issues. Anyone know if it is possible? > At this time all the members of the team see the bugs, but as you mention, not everybody in the mailing list. Perhaps there is a way to make the mailing list a read only member and subscribe it to the list? -- 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 Wed Jun 8 23:15:14 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 8 Jun 2011 23:15:14 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29169 ] rake creates ruby wrappers around non-ruby executables, causing them to fail Message-ID: <20110609031514.50D9B18583C4@rubyforge.org> Bugs item #29169, was opened at 2011-05-05 20:56 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29169&group_id=126 Category: other Group: None Status: Open Resolution: Rejected Priority: 3 Submitted By: Kevin Olbrich (olbrich) Assigned to: Ryan Davis (zenspider) Summary: rake creates ruby wrappers around non-ruby executables, causing them to fail Initial Comment: when providing executables with a gem, they get wrapped in a ruby wrapper that provides some support for using previous versions of a gem. If the executable is not a ruby file (e.g., a bash script, php, etc..) then the wrapper will fail. Suggestions: 1. allow the gemspec to force the gem to be installed with '--no-wrapper' and leave it to the developer to properly wrap executables. 2. check the shebang line of the executable and skip wrapping for anything that explicitly uses something other than ruby ---------------------------------------------------------------------- >Comment By: Kevin Olbrich (olbrich) Date: 2011-06-08 22:15 Message: https://github.com/rubygems/rubygems/issues/88 ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-06-07 18:50 Message: Hi! Believe it or not, we're moving to github's issue tracker! The pressure to move has been loud and clear, but for the longest time it didn't support the way we worked. Now that it has freeform labels it can support our workflow adequately. There is just one problem: Your bug is here and we don't want to lose you! What we'd like you to do is fairly painless and should only take a few minutes: Please file the _exact_ same ticket on github and provide a link back to this crufty old ticket so we can refer to any previous discussion that occurred. Once the new ticket is made, put a forwarding link to it here and close this ticket out. In a couple weeks, we'll track down the old tickets that are still open and decide what to do with them. We could have done this fairly automatically, but we really want you to do it so you're attached to the ticket and we can still communicate with you and keep a record of it. https://github.com/rubygems/rubygems/issues Thanks, The RubyGems Team ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-05-31 18:26 Message: I don't know of a good way to do this that works across platforms and makes sense. Rubygems is for ruby. If a file is in your gem's bindir and listed as a gem executable, it should be ruby. If your gem has "special needs" then it should do it out of band, like create a Rakefile that does your special steps for you and list the Rakefile as an extension in the spec. Or just use a post-install message telling people to install with --no-wrapper. Lemme know if I didn't understand something. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29169&group_id=126 From noreply at rubyforge.org Wed Jun 8 23:16:59 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 8 Jun 2011 23:16:59 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29169 ] rake creates ruby wrappers around non-ruby executables, causing them to fail Message-ID: <20110609031659.6322118583C5@rubyforge.org> Bugs item #29169, was opened at 2011-05-05 20:56 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29169&group_id=126 Category: other Group: None >Status: Closed Resolution: Rejected Priority: 3 Submitted By: Kevin Olbrich (olbrich) Assigned to: Ryan Davis (zenspider) Summary: rake creates ruby wrappers around non-ruby executables, causing them to fail Initial Comment: when providing executables with a gem, they get wrapped in a ruby wrapper that provides some support for using previous versions of a gem. If the executable is not a ruby file (e.g., a bash script, php, etc..) then the wrapper will fail. Suggestions: 1. allow the gemspec to force the gem to be installed with '--no-wrapper' and leave it to the developer to properly wrap executables. 2. check the shebang line of the executable and skip wrapping for anything that explicitly uses something other than ruby ---------------------------------------------------------------------- Comment By: Kevin Olbrich (olbrich) Date: 2011-06-08 22:15 Message: https://github.com/rubygems/rubygems/issues/88 ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-06-07 18:50 Message: Hi! Believe it or not, we're moving to github's issue tracker! The pressure to move has been loud and clear, but for the longest time it didn't support the way we worked. Now that it has freeform labels it can support our workflow adequately. There is just one problem: Your bug is here and we don't want to lose you! What we'd like you to do is fairly painless and should only take a few minutes: Please file the _exact_ same ticket on github and provide a link back to this crufty old ticket so we can refer to any previous discussion that occurred. Once the new ticket is made, put a forwarding link to it here and close this ticket out. In a couple weeks, we'll track down the old tickets that are still open and decide what to do with them. We could have done this fairly automatically, but we really want you to do it so you're attached to the ticket and we can still communicate with you and keep a record of it. https://github.com/rubygems/rubygems/issues Thanks, The RubyGems Team ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-05-31 18:26 Message: I don't know of a good way to do this that works across platforms and makes sense. Rubygems is for ruby. If a file is in your gem's bindir and listed as a gem executable, it should be ruby. If your gem has "special needs" then it should do it out of band, like create a Rakefile that does your special steps for you and list the Rakefile as an extension in the spec. Or just use a post-install message telling people to install with --no-wrapper. Lemme know if I didn't understand something. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29169&group_id=126 From noreply at rubyforge.org Thu Jun 9 02:46:10 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 9 Jun 2011 02:46:10 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29266 ] undefined method `name' for "actionmailer":String Message-ID: <20110609064611.5AABE3C807E@rubyforge.org> Bugs item #29266, was opened at 2011-06-09 16:46 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29266&group_id=126 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Behrang Saeedzadeh (behrangsa) Assigned to: Nobody (None) Summary: undefined method `name' for "actionmailer":String Initial Comment: After creating an RoR 2.3.9 using Ruby 1.8.7 I uncommented the following line # config.gem "bj" And then ran rake gems:install. Rake aborted and the following message was printed on the screen: $ rake gems:install (in /Users/Foo/Bar/Baz) rake aborted! undefined method `name' for "actionmailer":String ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29266&group_id=126 From noreply at rubyforge.org Thu Jun 9 06:52:37 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 9 Jun 2011 06:52:37 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29266 ] undefined method `name' for "actionmailer":String Message-ID: <20110609105237.66CF518583D0@rubyforge.org> Bugs item #29266, was opened at 2011-06-08 23:46 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29266&group_id=126 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Behrang Saeedzadeh (behrangsa) Assigned to: Nobody (None) >Summary: undefined method `name' for "actionmailer":String Initial Comment: After creating an RoR 2.3.9 using Ruby 1.8.7 I uncommented the following line # config.gem "bj" And then ran rake gems:install. Rake aborted and the following message was printed on the screen: $ rake gems:install (in /Users/Foo/Bar/Baz) rake aborted! undefined method `name' for "actionmailer":String ---------------------------------------------------------------------- >Comment By: Ryan Davis (zenspider) Date: 2011-06-09 03:52 Message: This is a bug in rails. The fix was just released in 2.3.12. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29266&group_id=126 From noreply at rubyforge.org Thu Jun 9 08:41:28 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 9 Jun 2011 08:41:28 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29266 ] undefined method `name' for " actionmailer" :String Message-ID: <20110609124128.AFF6C3C8086@rubyforge.org> Bugs item #29266, was opened at 2011-06-09 16:46 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29266&group_id=126 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Behrang Saeedzadeh (behrangsa) Assigned to: Nobody (None) >Summary: undefined method `name' for "actionmailer":String Initial Comment: After creating an RoR 2.3.9 using Ruby 1.8.7 I uncommented the following line # config.gem "bj" And then ran rake gems:install. Rake aborted and the following message was printed on the screen: $ rake gems:install (in /Users/Foo/Bar/Baz) rake aborted! undefined method `name' for "actionmailer":String ---------------------------------------------------------------------- >Comment By: Behrang Saeedzadeh (behrangsa) Date: 2011-06-09 22:41 Message: Thanks Ryan. Upgrading to 2.3.12 fixed the problem. But I still get these deprecation messages when I run the server: NOTE: Gem.source_index is deprecated, use Specification. It will be removed on or after 2011-11-01. Gem.source_index called from /Users/behrangsa/.rvm/gems/ruby-1.8.7-p334 at developious/gems/rails-2.3.12/lib/rails/gem_dependency.rb:21. NOTE: Gem::SourceIndex#initialize is deprecated with no replacement. It will be removed on or after 2011-11-01. Gem::SourceIndex#initialize called from /Users/behrangsa/.rvm/gems/ruby-1.8.7-p334 at developious/gems/rails- 2.3.12/lib/rails/vendor_gem_source_index.rb:100. Is there a way to fix/hide these messages? Cheers, Behrang ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-06-09 20:52 Message: This is a bug in rails. The fix was just released in 2.3.12. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29266&group_id=126 From noreply at rubyforge.org Thu Jun 9 08:49:32 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 9 Jun 2011 08:49:32 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29266 ] undefined method `name' for " actionmailer" :String Message-ID: <20110609124933.072353C8086@rubyforge.org> Bugs item #29266, was opened at 2011-06-09 03:46 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29266&group_id=126 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Behrang Saeedzadeh (behrangsa) Assigned to: Nobody (None) Summary: undefined method `name' for "actionmailer":String Initial Comment: After creating an RoR 2.3.9 using Ruby 1.8.7 I uncommented the following line # config.gem "bj" And then ran rake gems:install. Rake aborted and the following message was printed on the screen: $ rake gems:install (in /Users/Foo/Bar/Baz) rake aborted! undefined method `name' for "actionmailer":String ---------------------------------------------------------------------- >Comment By: Luis Lavena (luislavena) Date: 2011-06-09 09:49 Message: Hello, No, according to Aaron Patterson (Rails-Core) to fix that and make Rails use RubyGems 1.8.x API fully will require a complete overhaul of that part of Rails. Rails 3.0.x and 3.x are better candidates for getting that fixed. ---------------------------------------------------------------------- Comment By: Behrang Saeedzadeh (behrangsa) Date: 2011-06-09 09:41 Message: Thanks Ryan. Upgrading to 2.3.12 fixed the problem. But I still get these deprecation messages when I run the server: NOTE: Gem.source_index is deprecated, use Specification. It will be removed on or after 2011-11-01. Gem.source_index called from /Users/behrangsa/.rvm/gems/ruby-1.8.7-p334 at developious/gems/rails-2.3.12/lib/rails/gem_dependency.rb:21. NOTE: Gem::SourceIndex#initialize is deprecated with no replacement. It will be removed on or after 2011-11-01. Gem::SourceIndex#initialize called from /Users/behrangsa/.rvm/gems/ruby-1.8.7-p334 at developious/gems/rails- 2.3.12/lib/rails/vendor_gem_source_index.rb:100. Is there a way to fix/hide these messages? Cheers, Behrang ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-06-09 07:52 Message: This is a bug in rails. The fix was just released in 2.3.12. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29266&group_id=126 From evan at fallingsnow.net Thu Jun 9 13:42:29 2011 From: evan at fallingsnow.net (Evan Phoenix) Date: Thu, 9 Jun 2011 10:42:29 -0700 Subject: [Rubygems-developers] Documentation generation has changed In-Reply-To: <4DEEE16A.30305@soen.ca> References: <4DEEE16A.30305@soen.ca> Message-ID: See below. -- Evan Phoenix // evan at fallingsnow.net On Tuesday, June 7, 2011 at 7:41 PM, Loren Segal wrote: > Hi Eric, > > On 6/7/2011 8:23 PM, Eric Hodel wrote: > > Additionally the documentation types are available through the installer instance passed to the done_installing hook: > > > > Gem.done_installing do |installer, specs| > > if installer.document.include? 'pretend' then > > puts "Pretending to document: #{specs.map { |spec| spec.full_name }}" > > end > > end > > I take it that other documentation tools are expected to build plugins > in this fashion that perform the appropriate documentation generation. > However, In the case of static generation of HTML, it usually only makes > sense to have one tool run-- so is there a way for the plugin to cancel > the builtin rdoc hooks from running in this case? If so, what would be > the recommended way? If not, can such a method be added? The direction currently is focused on the developer having that control rather than a gem being able to take control when it's installed. If a user would like to use yard, they can set `:document: "yard"` in their .gemrc (could be the system one or the user one). We feel like this addresses the first concern, namely that users are able to specify yard generate all their docs. The 2nd issue how should a gem indicate "i'd like tool X to generate docs for me". This was what has_rdoc did previously. I've committed the ability to set metadata, so my plan was to allow a gem to specify a "document" key in the metadata would would function the same as the --document CLI option. This way, a gem can have control of how it's documentation be generated if it wishes. How do these sound? > > - Loren > _______________________________________________ > Rubygems-developers mailing list > http://rubyforge.org/projects/rubygems > Rubygems-developers at rubyforge.org (mailto:Rubygems-developers at rubyforge.org) > http://rubyforge.org/mailman/listinfo/rubygems-developers From jftucker at gmail.com Thu Jun 9 16:06:55 2011 From: jftucker at gmail.com (James Tucker) Date: Thu, 9 Jun 2011 13:06:55 -0700 Subject: [Rubygems-developers] Documentation generation has changed In-Reply-To: References: <4DEEE16A.30305@soen.ca> Message-ID: <9B203A40-6F4B-4862-B334-A8701668F67D@gmail.com> On Jun 9, 2011, at 10:42 AM, Evan Phoenix wrote: > See below. > > -- > Evan Phoenix // evan at fallingsnow.net > > > On Tuesday, June 7, 2011 at 7:41 PM, Loren Segal wrote: > >> Hi Eric, >> >> On 6/7/2011 8:23 PM, Eric Hodel wrote: >>> Additionally the documentation types are available through the installer instance passed to the done_installing hook: >>> >>> Gem.done_installing do |installer, specs| >>> if installer.document.include? 'pretend' then >>> puts "Pretending to document: #{specs.map { |spec| spec.full_name }}" >>> end >>> end >> >> I take it that other documentation tools are expected to build plugins >> in this fashion that perform the appropriate documentation generation. >> However, In the case of static generation of HTML, it usually only makes >> sense to have one tool run-- so is there a way for the plugin to cancel >> the builtin rdoc hooks from running in this case? If so, what would be >> the recommended way? If not, can such a method be added? > The direction currently is focused on the developer having that control rather than a gem being able to take control when it's installed. If a user would like to use yard, they can set `:document: "yard"` in their .gemrc (could be the system one or the user one). We feel like this addresses the first concern, namely that users are able to specify yard generate all their docs. > > The 2nd issue how should a gem indicate "i'd like tool X to generate docs for me". This was what has_rdoc did previously. I've committed the ability to set metadata, so my plan was to allow a gem to specify a "document" key in the metadata would would function the same as the --document CLI option. This way, a gem can have control of how it's documentation be generated if it wishes. > > How do these sound? Might it be sensible for that to indicate a document type/style rather than a tool, and then to infer "a compatible document generator", for future safety? >> >> - Loren >> _______________________________________________ >> Rubygems-developers mailing list >> http://rubyforge.org/projects/rubygems >> Rubygems-developers at rubyforge.org (mailto:Rubygems-developers at rubyforge.org) >> http://rubyforge.org/mailman/listinfo/rubygems-developers > > > _______________________________________________ > Rubygems-developers mailing list > http://rubyforge.org/projects/rubygems > Rubygems-developers at rubyforge.org > http://rubyforge.org/mailman/listinfo/rubygems-developers From dchelimsky at gmail.com Thu Jun 9 11:58:34 2011 From: dchelimsky at gmail.com (David Chelimsky) Date: Thu, 9 Jun 2011 10:58:34 -0500 Subject: [Rubygems-developers] no more redundant warnings References: <75F8701E-23AC-448C-805D-6A77301A5415@gmail.com> Message-ID: <9E5F55F2-CEA6-4773-9EDF-DF7B95186505@gmail.com> Hey @drbrain - just to close the loop on yesterday's twitter convo - having upgraded to rubygems-1.8.5, rails-2.3.12, and bundler-1.0.15 (released today?), I now see the warnings I expect to see, and only once. Thanks to all who worked to get this resolved. Cheers, David From steve at steveklabnik.com Tue Jun 7 20:16:32 2011 From: steve at steveklabnik.com (Steve Klabnik) Date: Tue, 7 Jun 2011 20:16:32 -0400 Subject: [Rubygems-developers] moving to github issues In-Reply-To: <7268E5FA-B7B8-42AB-82B2-D9B6E1EEAB1F@zenspider.com> References: <7268E5FA-B7B8-42AB-82B2-D9B6E1EEAB1F@zenspider.com> Message-ID: > As such... there be noise. I think I pretty much speak for everyone when I say... That's very much okay. :) On Tuesday, June 7, 2011 at 8:11 PM, Ryan Davis wrote: > I just activated github issues for rubygems and added a bunch of labels to help us replicate the workflow from rubyforge's issue tracker (eg resolution, category, and status). I've added a canned message to the 3 trackers we had and mass blatted all open tickets to get the owners to migrate their tickets to github issues. > > As such... there be noise. > > _______________________________________________ > Rubygems-developers mailing list > http://rubyforge.org/projects/rubygems > Rubygems-developers at rubyforge.org (mailto:Rubygems-developers at rubyforge.org) > http://rubyforge.org/mailman/listinfo/rubygems-developers From steve at steveklabnik.com Wed Jun 8 17:38:31 2011 From: steve at steveklabnik.com (Steve Klabnik) Date: Wed, 8 Jun 2011 17:38:31 -0400 Subject: [Rubygems-developers] github issues and the mailing list In-Reply-To: <2E2C993A-A050-443C-8AB3-5DD4E652EA11@zenspider.com> References: <2E2C993A-A050-443C-8AB3-5DD4E652EA11@zenspider.com> Message-ID: I know that it happens if you're 'involved', I'm not sure if there's an easy way to do it automatically. I do know that I'm on a few teams with projects and I don't always get emails, so I'm not sure. This is more of a "I don't think so" than a 'yes' kind of mail, I guess. On Wednesday, June 8, 2011 at 4:40 PM, Ryan Davis wrote: > Even tho it means twice as much mail for me, I liked that the old system was subscribed and publishing ticket activity to the mailing list. More eyeballs == better. I don't know of a way to make that happen for github issues. Anyone know if it is possible? > > _______________________________________________ > Rubygems-developers mailing list > http://rubyforge.org/projects/rubygems > Rubygems-developers at rubyforge.org (mailto:Rubygems-developers at rubyforge.org) > http://rubyforge.org/mailman/listinfo/rubygems-developers From steve at steveklabnik.com Wed Jun 8 18:26:08 2011 From: steve at steveklabnik.com (Steve Klabnik) Date: Wed, 8 Jun 2011 18:26:08 -0400 Subject: [Rubygems-developers] github issues and the mailing list In-Reply-To: References: <2E2C993A-A050-443C-8AB3-5DD4E652EA11@zenspider.com> Message-ID: <79279D320E4A46679EFED061A278817E@steveklabnik.com> I _think_ that the email hook only works on commits, not Issues, right? From evan at fallingsnow.net Thu Jun 9 17:47:14 2011 From: evan at fallingsnow.net (Evan Phoenix) Date: Thu, 9 Jun 2011 14:47:14 -0700 Subject: [Rubygems-developers] no more redundant warnings In-Reply-To: <9E5F55F2-CEA6-4773-9EDF-DF7B95186505@gmail.com> References: <75F8701E-23AC-448C-805D-6A77301A5415@gmail.com> <9E5F55F2-CEA6-4773-9EDF-DF7B95186505@gmail.com> Message-ID: <005031D29E31403EAA389F4A1149A74A@gmail.com> Hi David, No problem, thanks for hangin' in there with us. - Evan -- Evan Phoenix // evan at fallingsnow.net On Thursday, June 9, 2011 at 8:58 AM, David Chelimsky wrote: > Hey @drbrain - just to close the loop on yesterday's twitter convo - having upgraded to rubygems-1.8.5, rails-2.3.12, and bundler-1.0.15 (released today?), I now see the warnings I expect to see, and only once. > > Thanks to all who worked to get this resolved. > > Cheers, > David > > _______________________________________________ > Rubygems-developers mailing list > http://rubyforge.org/projects/rubygems > Rubygems-developers at rubyforge.org (mailto:Rubygems-developers at rubyforge.org) > http://rubyforge.org/mailman/listinfo/rubygems-developers From jftucker at gmail.com Thu Jun 9 17:51:44 2011 From: jftucker at gmail.com (James Tucker) Date: Thu, 9 Jun 2011 14:51:44 -0700 Subject: [Rubygems-developers] github issues and the mailing list In-Reply-To: <2E2C993A-A050-443C-8AB3-5DD4E652EA11@zenspider.com> References: <2E2C993A-A050-443C-8AB3-5DD4E652EA11@zenspider.com> Message-ID: <3DB4529F-18CA-4E58-B161-5BADE272C7A2@gmail.com> I believe it is. I'll take a look. On Jun 8, 2011, at 1:40 PM, Ryan Davis wrote: > Even tho it means twice as much mail for me, I liked that the old system was subscribed and publishing ticket activity to the mailing list. More eyeballs == better. I don't know of a way to make that happen for github issues. Anyone know if it is possible? > > _______________________________________________ > Rubygems-developers mailing list > http://rubyforge.org/projects/rubygems > Rubygems-developers at rubyforge.org > http://rubyforge.org/mailman/listinfo/rubygems-developers From jftucker at gmail.com Thu Jun 9 17:56:12 2011 From: jftucker at gmail.com (James Tucker) Date: Thu, 9 Jun 2011 14:56:12 -0700 Subject: [Rubygems-developers] github issues and the mailing list In-Reply-To: <2E2C993A-A050-443C-8AB3-5DD4E652EA11@zenspider.com> References: <2E2C993A-A050-443C-8AB3-5DD4E652EA11@zenspider.com> Message-ID: <9607E3BF-38AA-4F29-94EF-4AC4EA6C92AB@gmail.com> Hmm, maybe not so easily. Before organizations it was possible to do. As far as personal mail goes, you can easily disable / control that here: https://github.com/account/notifications HTH I can setup a bot to forward issues later unless someone else takes that on. On Jun 8, 2011, at 1:40 PM, Ryan Davis wrote: > Even tho it means twice as much mail for me, I liked that the old system was subscribed and publishing ticket activity to the mailing list. More eyeballs == better. I don't know of a way to make that happen for github issues. Anyone know if it is possible? > > _______________________________________________ > Rubygems-developers mailing list > http://rubyforge.org/projects/rubygems > Rubygems-developers at rubyforge.org > http://rubyforge.org/mailman/listinfo/rubygems-developers From evan at fallingsnow.net Thu Jun 9 18:07:59 2011 From: evan at fallingsnow.net (Evan Phoenix) Date: Thu, 9 Jun 2011 15:07:59 -0700 Subject: [Rubygems-developers] Documentation generation has changed In-Reply-To: <9B203A40-6F4B-4862-B334-A8701668F67D@gmail.com> References: <4DEEE16A.30305@soen.ca> <9B203A40-6F4B-4862-B334-A8701668F67D@gmail.com> Message-ID: <3E10DA57D4414FBFA7311837040E49A0@gmail.com> How's this for a description of how the doc system works: A doc plugin is just a post_install hook. Because they are hooks, they can not cancel each other out or generally know who is has run or will run next. All possible doc plugins will always be active and decide if they should run based on the value of the "document" variable. - The default doc plugin is triggered from the presence of "rdoc" and "ri" in document If a doc plugin is a meta plugin, thus wishes to delegate to another, it must simply use an API provided by another plugin. - For example, a plugin which wishes to download docs from the internet and generate docs rdoc second would simply call the Gem::RDoc class to do so. A gem which sets metadata['document'], it's contents will replace the document variable. - This allows a gem to override which doc format/tool should be used for it's docs The CLI or .gemrc can prevent a value from being removed from document by a gem by prefixing the value with a + sign. So if a gem sets metadata['document'] = 'evandoc' and on the CLI there is `--document +ri`, then the document variable will contain "ri", and "evandoc" - Evan -- Evan Phoenix // evan at fallingsnow.net On Thursday, June 9, 2011 at 1:06 PM, James Tucker wrote: > > On Jun 9, 2011, at 10:42 AM, Evan Phoenix wrote: > > > See below. > > > > -- > > Evan Phoenix // evan at fallingsnow.net (mailto:evan at fallingsnow.net) > > > > > > On Tuesday, June 7, 2011 at 7:41 PM, Loren Segal wrote: > > > > > Hi Eric, > > > > > > On 6/7/2011 8:23 PM, Eric Hodel wrote: > > > > Additionally the documentation types are available through the installer instance passed to the done_installing hook: > > > > > > > > Gem.done_installing do |installer, specs| > > > > if installer.document.include? 'pretend' then > > > > puts "Pretending to document: #{specs.map { |spec| spec.full_name }}" > > > > end > > > > end > > > > > > I take it that other documentation tools are expected to build plugins > > > in this fashion that perform the appropriate documentation generation. > > > However, In the case of static generation of HTML, it usually only makes > > > sense to have one tool run-- so is there a way for the plugin to cancel > > > the builtin rdoc hooks from running in this case? If so, what would be > > > the recommended way? If not, can such a method be added? > > The direction currently is focused on the developer having that control rather than a gem being able to take control when it's installed. If a user would like to use yard, they can set `:document: "yard"` in their .gemrc (could be the system one or the user one). We feel like this addresses the first concern, namely that users are able to specify yard generate all their docs. > > > > The 2nd issue how should a gem indicate "i'd like tool X to generate docs for me". This was what has_rdoc did previously. I've committed the ability to set metadata, so my plan was to allow a gem to specify a "document" key in the metadata would would function the same as the --document CLI option. This way, a gem can have control of how it's documentation be generated if it wishes. > > > > How do these sound? > > Might it be sensible for that to indicate a document type/style rather than a tool, and then to infer "a compatible document generator", for future safety? > > > > > > > - Loren > > > _______________________________________________ > > > Rubygems-developers mailing list > > > http://rubyforge.org/projects/rubygems > > > Rubygems-developers at rubyforge.org (mailto:Rubygems-developers at rubyforge.org) > > > http://rubyforge.org/mailman/listinfo/rubygems-developers > > > > > > _______________________________________________ > > Rubygems-developers mailing list > > http://rubyforge.org/projects/rubygems > > Rubygems-developers at rubyforge.org (mailto:Rubygems-developers at rubyforge.org) > > http://rubyforge.org/mailman/listinfo/rubygems-developers > > _______________________________________________ > Rubygems-developers mailing list > http://rubyforge.org/projects/rubygems > Rubygems-developers at rubyforge.org (mailto:Rubygems-developers at rubyforge.org) > http://rubyforge.org/mailman/listinfo/rubygems-developers From drbrain at segment7.net Thu Jun 9 18:51:45 2011 From: drbrain at segment7.net (Eric Hodel) Date: Thu, 9 Jun 2011 15:51:45 -0700 Subject: [Rubygems-developers] Documentation generation has changed In-Reply-To: <9B203A40-6F4B-4862-B334-A8701668F67D@gmail.com> References: <4DEEE16A.30305@soen.ca> <9B203A40-6F4B-4862-B334-A8701668F67D@gmail.com> Message-ID: On Jun 9, 2011, at 1:06 PM, James Tucker wrote: > On Jun 9, 2011, at 10:42 AM, Evan Phoenix wrote: >> The direction currently is focused on the developer having that control rather than a gem being able to take control when it's installed. If a user would like to use yard, they can set `:document: "yard"` in their .gemrc (could be the system one or the user one). We feel like this addresses the first concern, namely that users are able to specify yard generate all their docs. >> >> The 2nd issue how should a gem indicate "i'd like tool X to generate docs for me". This was what has_rdoc did previously. I've committed the ability to set metadata, so my plan was to allow a gem to specify a "document" key in the metadata would would function the same as the --document CLI option. This way, a gem can have control of how it's documentation be generated if it wishes. >> >> How do these sound? > > Might it be sensible for that to indicate a document type/style rather than a tool, and then to infer "a compatible document generator", for future safety? This type of feature should be a suggestion, not a commandment. When I install a gem I would rather see some documentation than no documentation. If the named tool doesn't isn't installed documentation generation should fall back to the user's preference via --document then to the default (rdoc). From drbrain at segment7.net Thu Jun 9 18:54:12 2011 From: drbrain at segment7.net (Eric Hodel) Date: Thu, 9 Jun 2011 15:54:12 -0700 Subject: [Rubygems-developers] github issues and the mailing list In-Reply-To: <2E2C993A-A050-443C-8AB3-5DD4E652EA11@zenspider.com> References: <2E2C993A-A050-443C-8AB3-5DD4E652EA11@zenspider.com> Message-ID: <672A70FF-C861-40B9-B8B9-E55019F8927D@segment7.net> On Jun 8, 2011, at 1:40 PM, Ryan Davis wrote: > Even tho it means twice as much mail for me, I liked that the old system was subscribed and publishing ticket activity to the mailing list. More eyeballs == better. I don't know of a way to make that happen for github issues. Anyone know if it is possible? My idea was to add a dummy user to the project then point its email address here. From evan at fallingsnow.net Thu Jun 9 19:07:28 2011 From: evan at fallingsnow.net (Evan Phoenix) Date: Thu, 9 Jun 2011 16:07:28 -0700 Subject: [Rubygems-developers] github issues and the mailing list In-Reply-To: <672A70FF-C861-40B9-B8B9-E55019F8927D@segment7.net> References: <2E2C993A-A050-443C-8AB3-5DD4E652EA11@zenspider.com> <672A70FF-C861-40B9-B8B9-E55019F8927D@segment7.net> Message-ID: <00A47294D9D744D0856039E37490021F@gmail.com> -- Evan Phoenix // evan at fallingsnow.net On Thursday, June 9, 2011 at 3:54 PM, Eric Hodel wrote: > On Jun 8, 2011, at 1:40 PM, Ryan Davis wrote: > > Even tho it means twice as much mail for me, I liked that the old system was subscribed and publishing ticket activity to the mailing list. More eyeballs == better. I don't know of a way to make that happen for github issues. Anyone know if it is possible? > > My idea was to add a dummy user to the project then point its email address here. Sounds like a fine solution. > _______________________________________________ > Rubygems-developers mailing list > http://rubyforge.org/projects/rubygems > Rubygems-developers at rubyforge.org (mailto:Rubygems-developers at rubyforge.org) > http://rubyforge.org/mailman/listinfo/rubygems-developers From evan at fallingsnow.net Thu Jun 9 19:31:52 2011 From: evan at fallingsnow.net (Evan Phoenix) Date: Thu, 9 Jun 2011 16:31:52 -0700 Subject: [Rubygems-developers] Documentation generation has changed In-Reply-To: References: <4DEEE16A.30305@soen.ca> <9B203A40-6F4B-4862-B334-A8701668F67D@gmail.com> Message-ID: <172758717D8040CD8E6DF0BBBDE2040A@gmail.com> See below. -- Evan Phoenix // evan at fallingsnow.net On Thursday, June 9, 2011 at 3:51 PM, Eric Hodel wrote: > On Jun 9, 2011, at 1:06 PM, James Tucker wrote: > > On Jun 9, 2011, at 10:42 AM, Evan Phoenix wrote: > > > The direction currently is focused on the developer having that control rather than a gem being able to take control when it's installed. If a user would like to use yard, they can set `:document: "yard"` in their .gemrc (could be the system one or the user one). We feel like this addresses the first concern, namely that users are able to specify yard generate all their docs. > > > > > > The 2nd issue how should a gem indicate "i'd like tool X to generate docs for me". This was what has_rdoc did previously. I've committed the ability to set metadata, so my plan was to allow a gem to specify a "document" key in the metadata would would function the same as the --document CLI option. This way, a gem can have control of how it's documentation be generated if it wishes. > > > > > > How do these sound? > > > > Might it be sensible for that to indicate a document type/style rather than a tool, and then to infer "a compatible document generator", for future safety? > > This type of feature should be a suggestion, not a commandment. When I install a gem I would rather see some documentation than no documentation. > > If the named tool doesn't isn't installed documentation generation should fall back to the user's preference via --document then to the default (rdoc). If a gem specifies "blah", how can rubygems know that there was no docs generated and therefore it should fallback? Because there is no coupling, it doesn't seem like there is a way to detect. Were you just thinking it would check a directory (and thus all doc tools are expected to put their generated docs in a certain directory) > _______________________________________________ > Rubygems-developers mailing list > http://rubyforge.org/projects/rubygems > Rubygems-developers at rubyforge.org (mailto:Rubygems-developers at rubyforge.org) > http://rubyforge.org/mailman/listinfo/rubygems-developers From luislavena at gmail.com Thu Jun 9 19:56:20 2011 From: luislavena at gmail.com (Luis Lavena) Date: Thu, 9 Jun 2011 19:56:20 -0400 Subject: [Rubygems-developers] github issues and the mailing list In-Reply-To: <672A70FF-C861-40B9-B8B9-E55019F8927D@segment7.net> References: <2E2C993A-A050-443C-8AB3-5DD4E652EA11@zenspider.com> <672A70FF-C861-40B9-B8B9-E55019F8927D@segment7.net> Message-ID: On Thu, Jun 9, 2011 at 6:54 PM, Eric Hodel wrote: > On Jun 8, 2011, at 1:40 PM, Ryan Davis wrote: >> Even tho it means twice as much mail for me, I liked that the old system was subscribed and publishing ticket activity to the mailing list. More eyeballs == better. I don't know of a way to make that happen for github issues. Anyone know if it is possible? > > My idea was to add a dummy user to the project then point its email address here. That is what I wanted to say :-P -- Luis Lavena AREA 17 - Perfection in design is achieved not when there is nothing more to add, but rather when there is nothing more to take away. Antoine de Saint-Exup?ry From jftucker at gmail.com Fri Jun 10 11:29:17 2011 From: jftucker at gmail.com (James Tucker) Date: Fri, 10 Jun 2011 08:29:17 -0700 Subject: [Rubygems-developers] github issues and the mailing list In-Reply-To: References: <2E2C993A-A050-443C-8AB3-5DD4E652EA11@zenspider.com> <672A70FF-C861-40B9-B8B9-E55019F8927D@segment7.net> Message-ID: <5847A6EC-16D5-431D-96BD-92245C616C47@gmail.com> On Jun 9, 2011, at 4:56 PM, Luis Lavena wrote: > On Thu, Jun 9, 2011 at 6:54 PM, Eric Hodel wrote: >> On Jun 8, 2011, at 1:40 PM, Ryan Davis wrote: >>> Even tho it means twice as much mail for me, I liked that the old system was subscribed and publishing ticket activity to the mailing list. More eyeballs == better. I don't know of a way to make that happen for github issues. Anyone know if it is possible? >> >> My idea was to add a dummy user to the project then point its email address here. > > That is what I wanted to say :-P The only problem is, you'll want to moderate password reset emails From drbrain at segment7.net Fri Jun 10 17:25:16 2011 From: drbrain at segment7.net (Eric Hodel) Date: Fri, 10 Jun 2011 14:25:16 -0700 Subject: [Rubygems-developers] Documentation generation has changed In-Reply-To: <172758717D8040CD8E6DF0BBBDE2040A@gmail.com> References: <4DEEE16A.30305@soen.ca> <9B203A40-6F4B-4862-B334-A8701668F67D@gmail.com> <172758717D8040CD8E6DF0BBBDE2040A@gmail.com> Message-ID: <8FD36068-3B87-4251-A30D-593ECB71944F@segment7.net> On Jun 9, 2011, at 4:31 PM, Evan Phoenix wrote: > On Thursday, June 9, 2011 at 3:51 PM, Eric Hodel wrote: >> On Jun 9, 2011, at 1:06 PM, James Tucker wrote: >>> Might it be sensible for that to indicate a document type/style rather than a tool, and then to infer "a compatible document generator", for future safety? >> >> This type of feature should be a suggestion, not a commandment. When I install a gem I would rather see some documentation than no documentation. >> >> If the named tool doesn't isn't installed documentation generation should fall back to the user's preference via --document then to the default (rdoc). > > If a gem specifies "blah", how can rubygems know that there was no docs generated and therefore it should fallback? Because there is no coupling, it doesn't seem like there is a way to detect. Were you just thinking it would check a directory (and thus all doc tools are expected to put their generated docs in a certain directory) We'll probably need more API around this, perhaps a way to register documentation types so RubyGems can detect if the preferred format is installed. From noreply at rubyforge.org Fri Jun 10 19:33:04 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 10 Jun 2011 19:33:04 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Patches-29269 ] Gem.set_paths fails on Etc.getpwuid.uid when running chrooted Message-ID: <20110610233304.71ED9185834E@rubyforge.org> Patches item #29269, was opened at 2011-06-11 01:33 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=577&aid=29269&group_id=126 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Jorge Jimenez (jjimenez) Assigned to: Nobody (None) Summary: Gem.set_paths fails on Etc.getpwuid.uid when running chrooted Initial Comment: In a chrooted environment with less privileges for /etc/passwd, method set_paths fails on Etc.getpwuid.uid call because current user is not allowed to read /etc/passwd file (for security matters). Changing Etc.getpwuid.uid by Process.uid solve this issue. I know this is not a bug, because /etc/passwd file must be readable by all users, but Etc.getpwuid.uid must first call getuid() function prior to call getpwuid() function and finally get the uid from the returned data, which is the same uid that Process.uid returns. So I suggest the following change in rubygems.rb: @@ -720,7 +720,7 @@ if 0 == File.expand_path(path).index(Gem.user_home) unless win_platform? then # only create by matching user - next if Etc.getpwuid.uid != File::Stat.new(Gem.user_home).uid + next if Process.uid != File::Stat.new(Gem.user_home).uid end end ensure_gem_subdirectories path Thus we can get the same behaviour, but using Process instead of Etc.getpwuid. Regards ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=577&aid=29269&group_id=126 From transfire at gmail.com Mon Jun 13 15:59:43 2011 From: transfire at gmail.com (Trans) Date: Mon, 13 Jun 2011 12:59:43 -0700 (PDT) Subject: [Rubygems-developers] Huge Message-ID: Why is Gems now dumping huge error reports like this? Could not find rdoc (~> 3) amongst [BlueCloth-1.0.0, ParseTree-3.0.4, ParseTree-3.0.3, ParseTree-2.2.0, RedCloth-4.2.7, RubyInline-3.8.3, RubyInline-3.8.1, RubyInline-3.7.0, ZenTest-4.1.4, ZenTest-4.0.0, aasm-2.1.5, abstract-1.0.0, actionmailer-3.0.0.beta, actionmailer-2.3.5, actionmailer-2.3.4, actionmailer-2.3.2, actionmailer-2.2.2, actionmailer-2.1.1, actionmailer-2.1.0, actionmailer-2.0.2, actionpack-3.0.0.beta, actionpack-2.3.5, actionpack-2.3.4, actionpack-2.3.2, actionpack-2.2.2, actionpack-2.1.1, actionpack-2.1.0, actionpack-2.0.2, activemodel-3.0.3, activemodel-3.0.0.beta, activerecord-3.0.3, activerecord-3.0.0.beta, activerecord-2.3.5, activerecord-2.3.4, activerecord-2.3.2, activerecord-2.2.2, activerecord-2.1.1, activerecord-2.1.0, activerecord-2.0.2, activeresource-3.0.0.beta, activeresource-2.3.5, activeresource-2.3.4, activeresource-2.3.2, activeresource-2.2.2, activeresource-2.1.1, activeresource-2.1.0, activeresource-2.0.2, activesupport-3.0.3, activesupport-3.0.0.beta, activesupport-2.3.5, activesupport-2.3.4, activesupport-2.3.2, activesupport-2.2.2, activesupport-2.1.1, activesupport-2.1.0, activesupport-2.0.2, acts_as_indexed-0.6.6, addressable-2.1.1, ae-1.3.0, albino-1.0, allison-2.0.3, ansi-1.2.2, ansi-1.1.0, arel-2.0.7, arel-0.2.1, aruba-0.1.9, aws-s3-0.6.2, babosa-0.2.2, bacon-1.1.0, bacon-1.0.0, bcrypt-ruby-2.1.4, bones-3.6.0, bones-2.5.1, bones-2.4.2, bones-2.1.0, bossman-0.4.1, bowline-0.6.1, builder-2.1.2, bundler-1.1.pre, bundler-1.0.9, bundler-0.9.25, chardet-0.9.0, chronos-0.1.0, classifier-1.3.1, coderay-0.9.3, coderay-0.9.1, coderay-0.8.312, coderay-0.8.260, color-1.4.1, colored-1.2, columnize-0.3.1, columnize-0.3.0, columnize-0.2, configuration-0.0.5, contest-0.1.2, creole-0.3.4, cucumber-0.8.3, cucumber-0.4.2, cucumber-0.3.104, cucumber-0.1.16, daemons-1.0.10, data_objects-0.10.1, dbd-mysql-0.4.4, dbi-0.4.3, deprecated-2.0.1, devise-1.1.5, diff-lcs-1.1.2, directory_watcher-1.2.0, dm-core-0.10.2, do_sqlite3-0.10.1.1, dragonfly-0.8.2, erector-0.8.1, erubis-2.6.6, erubis-2.6.5, evaluator-0.1.5, eventmachine-0.12.10, extlib-0.9.14, extlib-0.9.13, extlib-0.9.10, extlib-0.9.7, facets-2.9.0, facets-2.8.4, facets-2.8.0, facets-2.7.0, facets-2.6.0, fastri-0.3.1.1, fattr-2.1.0, friendly_id-2.3.2, friendly_id_globalize3-3.2.0, fuzzyhash-0.0.11, gash-0.1.3, gemcutter-0.5.0, gemedit-0.9.0, gettext-2.0.4, gettext-1.93.0, gherkin-2.3.7, github-markup-0.5.0, gitrb-0.0.8, gitrb-0.0.7, globalize3-0.1.0.beta, gollum-1.0.1, grancher-0.1.5, grancher-0.1, grit-2.4.1, grosser-parallel-0.3.1, grosser-parallel-0.2.0, haml-3.0.18, haml-2.2.20, haml-2.2.6, haml-2.2.2, haml-2.0.10, hashie-0.2.0, heroku-1.6.4, highline-1.5.2, hitimes-1.0.4, hoe-2.3.3, hoe-1.10.0, hoe-1.8.0, hoe-1.6.0, hpricot-0.8.4, html5-0.10.0, http_router-0.2.5, httpclient-2.1.5.2, httpclient-2.1.4, httpclient-2.1.2, i18n-0.4.1, i18n-0.3.3, imaginator-0.1.5, innate-2011.04, innate-2010.01, json-1.5.1, json-1.2.0, json_pure-1.4.6, json_pure-1.4.3, json_pure-1.2.0, ko-1.0.0, ko-0.0.1, kramdown-0.10.0, launchy-0.3.5, less-1.2.21, libxml-ruby-2.0.5, linecache-0.43, liquid-2.0.0, little-plugger-1.1.2, locale-2.0.4, looksee-0.2.1, loquacious-1.7.0, m4dbi-0.6.2, macaddr-1.0.0, mail-2.2.5, mail-2.1.2, markaby-0.5, maruku-0.6.0, maruku-0.5.9, mechanize-0.9.3, mechanize-0.9.2, mechanize-0.8.4, memcache- client-1.7.8, metaid-1.0, mime-types-1.16, mimemagic-0.1.2, minad-rack- esi-0.1.8, minitest-2.0.2, minitest-1.6.0, miniunit-1.2.1, mocha-0.9.8, mocha-0.9.5, mocha-0.9.1, mojombo-jekyll-0.5.4, mojombo- jekyll-0.5.3, moretea-awesome_nested_set-1.4.3.1, mustache-0.11.2, mutter-0.5.3, mysql-2.8.1, mysql-2.7, net-scp-1.0.2, net-ssh-2.0.15, net-ssh-2.0.13, newgem-1.5.2, newgem-1.2.3, nokogiri-1.4.4, open4-0.9.6, ore-core-0.1.0, ore-tasks-0.3.0, oyster-0.9.3, oyster-0.9.1, packr-3.1.0, packr-1.0.2, padrino-admin-0.9.13, padrino- admin-0.9.10, padrino-core-0.9.13, padrino-core-0.9.10, padrino- gen-0.9.13, padrino-gen-0.9.10, padrino-helpers-0.9.13, padrino- helpers-0.9.10, polyglot-0.3.1, polyglot-0.2.9, polyglot-0.2.5, postgres-0.7.9.2008.01.28, prawn-0.5.1, prawn-0.4.1, prawn-core-0.5.1, prawn-format-0.2.1, prawn-layout-0.2.1, prawn-layout-0.1.0, qed-2.3.0, quality_extensions-1.1.6, qwandry-0.0.3, rack-1.1.0, rack-1.0.1, rack-1.0.0, rack-0.9.1, rack-0.4.0, rack-cache-0.5.2, rack- embed-0.0.1, rack-esi-0.1.2, rack-flash-0.1.1, rack-mount-0.6.13, rack- mount-0.6.3, rack-mount-0.6.1, rack-mount-0.6.0, rack-mount-0.4.7, rack-test-0.5.7, rack-test-0.5.4, rack-test-0.5.3, radiant-0.9.1, radiant-0.8.2, radius-0.6.1, radius-0.5.1, rails-2.3.5, rails-2.3.4, rails-2.3.2, rails-2.2.2, rails-2.1.1, rails-2.1.0, rails-2.0.2, railties-3.0.0.beta, rake-0.8.7, rake-0.8.4, rake-0.8.3, rake-0.8.1, rake-compiler-0.7.0, ramaze-2011.01.30, rcov-0.9.9, rdazzle-1.4.0, rdiscount-1.6.8, rdoc-2.5.11, rdoc-data-2.5.3, rdoc-shomen-0.1.0, rdoc_html_templates-2.3.0, red-4.1.7, red-3.5.0, redcar-0.11, reek-1.2.8, rest-client-1.2.0, richunits-0.5.0, rio-0.4.2, rio-0.4.1, rmagick-2.12.2, ronn-0.7.3, rspec-2.0.0, rspec-1.2.8, rspec-1.1.12, rspec-1.1.3, rspec-1.1.2, rspec-core-2.0.0, rspec-expectations-2.0.0, rspec-mocks-2.0.0, rubigen-1.5.2, ruby-breakpoint-0.5.1, ruby- debug-0.10.4, ruby-debug-base-0.10.4, ruby-growl-1.0.1, ruby- mysql-2.9.2, ruby-prof-0.10.7, ruby2ruby-1.2.4, ruby2ruby-1.2.2, ruby2ruby-1.1.9, ruby_parser-2.0.4, ruby_parser-2.0.3, rubyforge-2.0.4, rubyforge-2.0.0, rubyforge-1.0.4, rubyforge-1.0.3, rubyforge-1.0.0, rubygems-update-1.8.2, rubygems-update-1.7.2, rubygems-update-1.3.7, rubygems-update-1.3.6, rubygems-update-1.3.5, rubygems-update-1.3.4, rubygems-update-1.3.1, rubygems-update-1.2.0, rubygems-update-1.0.1, rubyjs-0.8.0, rubypants-0.2.0, rubyscript2exe-0.5.3, rubyzip-0.9.4, rubyzip2-2.0.1, rvm-0.0.59, s3sync-1.2.5, sanitize-1.1.0, sequel-3.9.0, session-3.1.0, sexp_processor-3.0.3, sexp_processor-3.0.1, shoulda-2.11.3, sinatra-1.2.6, sinatra-1.0, sinatra-0.9.4, sinatra-0.9.1.1, sinatra_warden-0.2.0.2, slim_scrooge-1.0.5, sqlite3-1.3.3, sqlite3- ruby-1.3.3, sqlite3-ruby-1.2.5, stemmer-1.0.1, supermodel-0.1.0, syntax-1.0.0, templater-1.0.0, tenjin-0.6.1, term-ansicolor-1.0.5, term-ansicolor-1.0.4, term-ansicolor-1.0.3, termios-0.9.4, test- unit-2.0.3, test-unit-2.0.2, text-format-1.0.0, text-hyphen-1.0.0, thin-1.2.11, thor-0.14.6, thor-0.13.3, tilt-1.3, tilt-0.8, tilt-0.5, tilt-0.3, tracepoint-1.1, treetop-1.4.8, treetop-1.4.2, treetop-1.2.4, trollop-1.16.2, turn-0.8.1, tzinfo-0.3.24, tzinfo-0.3.16, unroller-1.0.0, url_mount-0.2.1, usher-0.8.3, uuid-2.0.2, uuid-2.0.1, uuidtools-2.0.0, uuidtools-1.0.7, uuidtools-1.0.3, vclog-1.6.0, warden-1.0.3, warden-0.10.2, watchr-0.7, wedge-0.0.1, will_paginate-2.3.12, wirble-0.1.3, wirble-0.1.2, wx_sugar-0.1.22, wxruby-2.0.0-x86_64-linux, xattr-0.1, xcb-0.0.1, xdg-0.5.2, xdg-0.5.1, xdg-0.4.0, xml-simple-1.0.12] I think I could have managed with just "Could not find rdoc (~> 3)". From jftucker at gmail.com Mon Jun 13 20:24:16 2011 From: jftucker at gmail.com (James Tucker) Date: Mon, 13 Jun 2011 17:24:16 -0700 Subject: [Rubygems-developers] Huge In-Reply-To: References: Message-ID: <093E1993-F971-4487-B79B-09CA6E966EAA@gmail.com> It would be more correct to show all of the gems which have a matched name. On Jun 13, 2011, at 12:59 PM, Trans wrote: > Why is Gems now dumping huge error reports like this? > > Could not find rdoc (~> 3) amongst [BlueCloth-1.0.0, ParseTree-3.0.4, > ParseTree-3.0.3, ParseTree-2.2.0, RedCloth-4.2.7, RubyInline-3.8.3, > RubyInline-3.8.1, RubyInline-3.7.0, ZenTest-4.1.4, ZenTest-4.0.0, > aasm-2.1.5, abstract-1.0.0, actionmailer-3.0.0.beta, > actionmailer-2.3.5, actionmailer-2.3.4, actionmailer-2.3.2, > actionmailer-2.2.2, actionmailer-2.1.1, actionmailer-2.1.0, > actionmailer-2.0.2, actionpack-3.0.0.beta, actionpack-2.3.5, > actionpack-2.3.4, actionpack-2.3.2, actionpack-2.2.2, > actionpack-2.1.1, actionpack-2.1.0, actionpack-2.0.2, > activemodel-3.0.3, activemodel-3.0.0.beta, activerecord-3.0.3, > activerecord-3.0.0.beta, activerecord-2.3.5, activerecord-2.3.4, > activerecord-2.3.2, activerecord-2.2.2, activerecord-2.1.1, > activerecord-2.1.0, activerecord-2.0.2, activeresource-3.0.0.beta, > activeresource-2.3.5, activeresource-2.3.4, activeresource-2.3.2, > activeresource-2.2.2, activeresource-2.1.1, activeresource-2.1.0, > activeresource-2.0.2, activesupport-3.0.3, activesupport-3.0.0.beta, > activesupport-2.3.5, activesupport-2.3.4, activesupport-2.3.2, > activesupport-2.2.2, activesupport-2.1.1, activesupport-2.1.0, > activesupport-2.0.2, acts_as_indexed-0.6.6, addressable-2.1.1, > ae-1.3.0, albino-1.0, allison-2.0.3, ansi-1.2.2, ansi-1.1.0, > arel-2.0.7, arel-0.2.1, aruba-0.1.9, aws-s3-0.6.2, babosa-0.2.2, > bacon-1.1.0, bacon-1.0.0, bcrypt-ruby-2.1.4, bones-3.6.0, bones-2.5.1, > bones-2.4.2, bones-2.1.0, bossman-0.4.1, bowline-0.6.1, builder-2.1.2, > bundler-1.1.pre, bundler-1.0.9, bundler-0.9.25, chardet-0.9.0, > chronos-0.1.0, classifier-1.3.1, coderay-0.9.3, coderay-0.9.1, > coderay-0.8.312, coderay-0.8.260, color-1.4.1, colored-1.2, > columnize-0.3.1, columnize-0.3.0, columnize-0.2, configuration-0.0.5, > contest-0.1.2, creole-0.3.4, cucumber-0.8.3, cucumber-0.4.2, > cucumber-0.3.104, cucumber-0.1.16, daemons-1.0.10, > data_objects-0.10.1, dbd-mysql-0.4.4, dbi-0.4.3, deprecated-2.0.1, > devise-1.1.5, diff-lcs-1.1.2, directory_watcher-1.2.0, dm-core-0.10.2, > do_sqlite3-0.10.1.1, dragonfly-0.8.2, erector-0.8.1, erubis-2.6.6, > erubis-2.6.5, evaluator-0.1.5, eventmachine-0.12.10, extlib-0.9.14, > extlib-0.9.13, extlib-0.9.10, extlib-0.9.7, facets-2.9.0, > facets-2.8.4, facets-2.8.0, facets-2.7.0, facets-2.6.0, > fastri-0.3.1.1, fattr-2.1.0, friendly_id-2.3.2, > friendly_id_globalize3-3.2.0, fuzzyhash-0.0.11, gash-0.1.3, > gemcutter-0.5.0, gemedit-0.9.0, gettext-2.0.4, gettext-1.93.0, > gherkin-2.3.7, github-markup-0.5.0, gitrb-0.0.8, gitrb-0.0.7, > globalize3-0.1.0.beta, gollum-1.0.1, grancher-0.1.5, grancher-0.1, > grit-2.4.1, grosser-parallel-0.3.1, grosser-parallel-0.2.0, > haml-3.0.18, haml-2.2.20, haml-2.2.6, haml-2.2.2, haml-2.0.10, > hashie-0.2.0, heroku-1.6.4, highline-1.5.2, hitimes-1.0.4, hoe-2.3.3, > hoe-1.10.0, hoe-1.8.0, hoe-1.6.0, hpricot-0.8.4, html5-0.10.0, > http_router-0.2.5, httpclient-2.1.5.2, httpclient-2.1.4, > httpclient-2.1.2, i18n-0.4.1, i18n-0.3.3, imaginator-0.1.5, > innate-2011.04, innate-2010.01, json-1.5.1, json-1.2.0, > json_pure-1.4.6, json_pure-1.4.3, json_pure-1.2.0, ko-1.0.0, ko-0.0.1, > kramdown-0.10.0, launchy-0.3.5, less-1.2.21, libxml-ruby-2.0.5, > linecache-0.43, liquid-2.0.0, little-plugger-1.1.2, locale-2.0.4, > looksee-0.2.1, loquacious-1.7.0, m4dbi-0.6.2, macaddr-1.0.0, > mail-2.2.5, mail-2.1.2, markaby-0.5, maruku-0.6.0, maruku-0.5.9, > mechanize-0.9.3, mechanize-0.9.2, mechanize-0.8.4, memcache- > client-1.7.8, metaid-1.0, mime-types-1.16, mimemagic-0.1.2, minad-rack- > esi-0.1.8, minitest-2.0.2, minitest-1.6.0, miniunit-1.2.1, > mocha-0.9.8, mocha-0.9.5, mocha-0.9.1, mojombo-jekyll-0.5.4, mojombo- > jekyll-0.5.3, moretea-awesome_nested_set-1.4.3.1, mustache-0.11.2, > mutter-0.5.3, mysql-2.8.1, mysql-2.7, net-scp-1.0.2, net-ssh-2.0.15, > net-ssh-2.0.13, newgem-1.5.2, newgem-1.2.3, nokogiri-1.4.4, > open4-0.9.6, ore-core-0.1.0, ore-tasks-0.3.0, oyster-0.9.3, > oyster-0.9.1, packr-3.1.0, packr-1.0.2, padrino-admin-0.9.13, padrino- > admin-0.9.10, padrino-core-0.9.13, padrino-core-0.9.10, padrino- > gen-0.9.13, padrino-gen-0.9.10, padrino-helpers-0.9.13, padrino- > helpers-0.9.10, polyglot-0.3.1, polyglot-0.2.9, polyglot-0.2.5, > postgres-0.7.9.2008.01.28, prawn-0.5.1, prawn-0.4.1, prawn-core-0.5.1, > prawn-format-0.2.1, prawn-layout-0.2.1, prawn-layout-0.1.0, qed-2.3.0, > quality_extensions-1.1.6, qwandry-0.0.3, rack-1.1.0, rack-1.0.1, > rack-1.0.0, rack-0.9.1, rack-0.4.0, rack-cache-0.5.2, rack- > embed-0.0.1, rack-esi-0.1.2, rack-flash-0.1.1, rack-mount-0.6.13, rack- > mount-0.6.3, rack-mount-0.6.1, rack-mount-0.6.0, rack-mount-0.4.7, > rack-test-0.5.7, rack-test-0.5.4, rack-test-0.5.3, radiant-0.9.1, > radiant-0.8.2, radius-0.6.1, radius-0.5.1, rails-2.3.5, rails-2.3.4, > rails-2.3.2, rails-2.2.2, rails-2.1.1, rails-2.1.0, rails-2.0.2, > railties-3.0.0.beta, rake-0.8.7, rake-0.8.4, rake-0.8.3, rake-0.8.1, > rake-compiler-0.7.0, ramaze-2011.01.30, rcov-0.9.9, rdazzle-1.4.0, > rdiscount-1.6.8, rdoc-2.5.11, rdoc-data-2.5.3, rdoc-shomen-0.1.0, > rdoc_html_templates-2.3.0, red-4.1.7, red-3.5.0, redcar-0.11, > reek-1.2.8, rest-client-1.2.0, richunits-0.5.0, rio-0.4.2, rio-0.4.1, > rmagick-2.12.2, ronn-0.7.3, rspec-2.0.0, rspec-1.2.8, rspec-1.1.12, > rspec-1.1.3, rspec-1.1.2, rspec-core-2.0.0, rspec-expectations-2.0.0, > rspec-mocks-2.0.0, rubigen-1.5.2, ruby-breakpoint-0.5.1, ruby- > debug-0.10.4, ruby-debug-base-0.10.4, ruby-growl-1.0.1, ruby- > mysql-2.9.2, ruby-prof-0.10.7, ruby2ruby-1.2.4, ruby2ruby-1.2.2, > ruby2ruby-1.1.9, ruby_parser-2.0.4, ruby_parser-2.0.3, > rubyforge-2.0.4, rubyforge-2.0.0, rubyforge-1.0.4, rubyforge-1.0.3, > rubyforge-1.0.0, rubygems-update-1.8.2, rubygems-update-1.7.2, > rubygems-update-1.3.7, rubygems-update-1.3.6, rubygems-update-1.3.5, > rubygems-update-1.3.4, rubygems-update-1.3.1, rubygems-update-1.2.0, > rubygems-update-1.0.1, rubyjs-0.8.0, rubypants-0.2.0, > rubyscript2exe-0.5.3, rubyzip-0.9.4, rubyzip2-2.0.1, rvm-0.0.59, > s3sync-1.2.5, sanitize-1.1.0, sequel-3.9.0, session-3.1.0, > sexp_processor-3.0.3, sexp_processor-3.0.1, shoulda-2.11.3, > sinatra-1.2.6, sinatra-1.0, sinatra-0.9.4, sinatra-0.9.1.1, > sinatra_warden-0.2.0.2, slim_scrooge-1.0.5, sqlite3-1.3.3, sqlite3- > ruby-1.3.3, sqlite3-ruby-1.2.5, stemmer-1.0.1, supermodel-0.1.0, > syntax-1.0.0, templater-1.0.0, tenjin-0.6.1, term-ansicolor-1.0.5, > term-ansicolor-1.0.4, term-ansicolor-1.0.3, termios-0.9.4, test- > unit-2.0.3, test-unit-2.0.2, text-format-1.0.0, text-hyphen-1.0.0, > thin-1.2.11, thor-0.14.6, thor-0.13.3, tilt-1.3, tilt-0.8, tilt-0.5, > tilt-0.3, tracepoint-1.1, treetop-1.4.8, treetop-1.4.2, treetop-1.2.4, > trollop-1.16.2, turn-0.8.1, tzinfo-0.3.24, tzinfo-0.3.16, > unroller-1.0.0, url_mount-0.2.1, usher-0.8.3, uuid-2.0.2, uuid-2.0.1, > uuidtools-2.0.0, uuidtools-1.0.7, uuidtools-1.0.3, vclog-1.6.0, > warden-1.0.3, warden-0.10.2, watchr-0.7, wedge-0.0.1, > will_paginate-2.3.12, wirble-0.1.3, wirble-0.1.2, wx_sugar-0.1.22, > wxruby-2.0.0-x86_64-linux, xattr-0.1, xcb-0.0.1, xdg-0.5.2, xdg-0.5.1, > xdg-0.4.0, xml-simple-1.0.12] > > I think I could have managed with just "Could not find rdoc (~> 3)". > _______________________________________________ > Rubygems-developers mailing list > http://rubyforge.org/projects/rubygems > Rubygems-developers at rubyforge.org > http://rubyforge.org/mailman/listinfo/rubygems-developers From evan at fallingsnow.net Mon Jun 13 20:32:52 2011 From: evan at fallingsnow.net (Evan Phoenix) Date: Mon, 13 Jun 2011 17:32:52 -0700 Subject: [Rubygems-developers] Huge In-Reply-To: <093E1993-F971-4487-B79B-09CA6E966EAA@gmail.com> References: <093E1993-F971-4487-B79B-09CA6E966EAA@gmail.com> Message-ID: Feel free to open an issue about this and we can add some code to shorten the list. -- Evan Phoenix // evan at fallingsnow.net On Monday, June 13, 2011 at 5:24 PM, James Tucker wrote: > It would be more correct to show all of the gems which have a matched name. > > On Jun 13, 2011, at 12:59 PM, Trans wrote: > > > Why is Gems now dumping huge error reports like this? > > > > Could not find rdoc (~> 3) amongst [BlueCloth-1.0.0, ParseTree-3.0.4, > > ParseTree-3.0.3, ParseTree-2.2.0, RedCloth-4.2.7, RubyInline-3.8.3, > > RubyInline-3.8.1, RubyInline-3.7.0, ZenTest-4.1.4, ZenTest-4.0.0, > > aasm-2.1.5, abstract-1.0.0, actionmailer-3.0.0.beta, > > actionmailer-2.3.5, actionmailer-2.3.4, actionmailer-2.3.2, > > actionmailer-2.2.2, actionmailer-2.1.1, actionmailer-2.1.0, > > actionmailer-2.0.2, actionpack-3.0.0.beta, actionpack-2.3.5, > > actionpack-2.3.4, actionpack-2.3.2, actionpack-2.2.2, > > actionpack-2.1.1, actionpack-2.1.0, actionpack-2.0.2, > > activemodel-3.0.3, activemodel-3.0.0.beta, activerecord-3.0.3, > > activerecord-3.0.0.beta, activerecord-2.3.5, activerecord-2.3.4, > > activerecord-2.3.2, activerecord-2.2.2, activerecord-2.1.1, > > activerecord-2.1.0, activerecord-2.0.2, activeresource-3.0.0.beta, > > activeresource-2.3.5, activeresource-2.3.4, activeresource-2.3.2, > > activeresource-2.2.2, activeresource-2.1.1, activeresource-2.1.0, > > activeresource-2.0.2, activesupport-3.0.3, activesupport-3.0.0.beta, > > activesupport-2.3.5, activesupport-2.3.4, activesupport-2.3.2, > > activesupport-2.2.2, activesupport-2.1.1, activesupport-2.1.0, > > activesupport-2.0.2, acts_as_indexed-0.6.6, addressable-2.1.1, > > ae-1.3.0, albino-1.0, allison-2.0.3, ansi-1.2.2, ansi-1.1.0, > > arel-2.0.7, arel-0.2.1, aruba-0.1.9, aws-s3-0.6.2, babosa-0.2.2, > > bacon-1.1.0, bacon-1.0.0, bcrypt-ruby-2.1.4, bones-3.6.0, bones-2.5.1, > > bones-2.4.2, bones-2.1.0, bossman-0.4.1, bowline-0.6.1, builder-2.1.2, > > bundler-1.1.pre, bundler-1.0.9, bundler-0.9.25, chardet-0.9.0, > > chronos-0.1.0, classifier-1.3.1, coderay-0.9.3, coderay-0.9.1, > > coderay-0.8.312, coderay-0.8.260, color-1.4.1, colored-1.2, > > columnize-0.3.1, columnize-0.3.0, columnize-0.2, configuration-0.0.5, > > contest-0.1.2, creole-0.3.4, cucumber-0.8.3, cucumber-0.4.2, > > cucumber-0.3.104, cucumber-0.1.16, daemons-1.0.10, > > data_objects-0.10.1, dbd-mysql-0.4.4, dbi-0.4.3, deprecated-2.0.1, > > devise-1.1.5, diff-lcs-1.1.2, directory_watcher-1.2.0, dm-core-0.10.2, > > do_sqlite3-0.10.1.1, dragonfly-0.8.2, erector-0.8.1, erubis-2.6.6, > > erubis-2.6.5, evaluator-0.1.5, eventmachine-0.12.10, extlib-0.9.14, > > extlib-0.9.13, extlib-0.9.10, extlib-0.9.7, facets-2.9.0, > > facets-2.8.4, facets-2.8.0, facets-2.7.0, facets-2.6.0, > > fastri-0.3.1.1, fattr-2.1.0, friendly_id-2.3.2, > > friendly_id_globalize3-3.2.0, fuzzyhash-0.0.11, gash-0.1.3, > > gemcutter-0.5.0, gemedit-0.9.0, gettext-2.0.4, gettext-1.93.0, > > gherkin-2.3.7, github-markup-0.5.0, gitrb-0.0.8, gitrb-0.0.7, > > globalize3-0.1.0.beta, gollum-1.0.1, grancher-0.1.5, grancher-0.1, > > grit-2.4.1, grosser-parallel-0.3.1, grosser-parallel-0.2.0, > > haml-3.0.18, haml-2.2.20, haml-2.2.6, haml-2.2.2, haml-2.0.10, > > hashie-0.2.0, heroku-1.6.4, highline-1.5.2, hitimes-1.0.4, hoe-2.3.3, > > hoe-1.10.0, hoe-1.8.0, hoe-1.6.0, hpricot-0.8.4, html5-0.10.0, > > http_router-0.2.5, httpclient-2.1.5.2, httpclient-2.1.4, > > httpclient-2.1.2, i18n-0.4.1, i18n-0.3.3, imaginator-0.1.5, > > innate-2011.04, innate-2010.01, json-1.5.1, json-1.2.0, > > json_pure-1.4.6, json_pure-1.4.3, json_pure-1.2.0, ko-1.0.0, ko-0.0.1, > > kramdown-0.10.0, launchy-0.3.5, less-1.2.21, libxml-ruby-2.0.5, > > linecache-0.43, liquid-2.0.0, little-plugger-1.1.2, locale-2.0.4, > > looksee-0.2.1, loquacious-1.7.0, m4dbi-0.6.2, macaddr-1.0.0, > > mail-2.2.5, mail-2.1.2, markaby-0.5, maruku-0.6.0, maruku-0.5.9, > > mechanize-0.9.3, mechanize-0.9.2, mechanize-0.8.4, memcache- > > client-1.7.8, metaid-1.0, mime-types-1.16, mimemagic-0.1.2, minad-rack- > > esi-0.1.8, minitest-2.0.2, minitest-1.6.0, miniunit-1.2.1, > > mocha-0.9.8, mocha-0.9.5, mocha-0.9.1, mojombo-jekyll-0.5.4, mojombo- > > jekyll-0.5.3, moretea-awesome_nested_set-1.4.3.1, mustache-0.11.2, > > mutter-0.5.3, mysql-2.8.1, mysql-2.7, net-scp-1.0.2, net-ssh-2.0.15, > > net-ssh-2.0.13, newgem-1.5.2, newgem-1.2.3, nokogiri-1.4.4, > > open4-0.9.6, ore-core-0.1.0, ore-tasks-0.3.0, oyster-0.9.3, > > oyster-0.9.1, packr-3.1.0, packr-1.0.2, padrino-admin-0.9.13, padrino- > > admin-0.9.10, padrino-core-0.9.13, padrino-core-0.9.10, padrino- > > gen-0.9.13, padrino-gen-0.9.10, padrino-helpers-0.9.13, padrino- > > helpers-0.9.10, polyglot-0.3.1, polyglot-0.2.9, polyglot-0.2.5, > > postgres-0.7.9.2008.01.28, prawn-0.5.1, prawn-0.4.1, prawn-core-0.5.1, > > prawn-format-0.2.1, prawn-layout-0.2.1, prawn-layout-0.1.0, qed-2.3.0, > > quality_extensions-1.1.6, qwandry-0.0.3, rack-1.1.0, rack-1.0.1, > > rack-1.0.0, rack-0.9.1, rack-0.4.0, rack-cache-0.5.2, rack- > > embed-0.0.1, rack-esi-0.1.2, rack-flash-0.1.1, rack-mount-0.6.13, rack- > > mount-0.6.3, rack-mount-0.6.1, rack-mount-0.6.0, rack-mount-0.4.7, > > rack-test-0.5.7, rack-test-0.5.4, rack-test-0.5.3, radiant-0.9.1, > > radiant-0.8.2, radius-0.6.1, radius-0.5.1, rails-2.3.5, rails-2.3.4, > > rails-2.3.2, rails-2.2.2, rails-2.1.1, rails-2.1.0, rails-2.0.2, > > railties-3.0.0.beta, rake-0.8.7, rake-0.8.4, rake-0.8.3, rake-0.8.1, > > rake-compiler-0.7.0, ramaze-2011.01.30, rcov-0.9.9, rdazzle-1.4.0, > > rdiscount-1.6.8, rdoc-2.5.11, rdoc-data-2.5.3, rdoc-shomen-0.1.0, > > rdoc_html_templates-2.3.0, red-4.1.7, red-3.5.0, redcar-0.11, > > reek-1.2.8, rest-client-1.2.0, richunits-0.5.0, rio-0.4.2, rio-0.4.1, > > rmagick-2.12.2, ronn-0.7.3, rspec-2.0.0, rspec-1.2.8, rspec-1.1.12, > > rspec-1.1.3, rspec-1.1.2, rspec-core-2.0.0, rspec-expectations-2.0.0, > > rspec-mocks-2.0.0, rubigen-1.5.2, ruby-breakpoint-0.5.1, ruby- > > debug-0.10.4, ruby-debug-base-0.10.4, ruby-growl-1.0.1, ruby- > > mysql-2.9.2, ruby-prof-0.10.7, ruby2ruby-1.2.4, ruby2ruby-1.2.2, > > ruby2ruby-1.1.9, ruby_parser-2.0.4, ruby_parser-2.0.3, > > rubyforge-2.0.4, rubyforge-2.0.0, rubyforge-1.0.4, rubyforge-1.0.3, > > rubyforge-1.0.0, rubygems-update-1.8.2, rubygems-update-1.7.2, > > rubygems-update-1.3.7, rubygems-update-1.3.6, rubygems-update-1.3.5, > > rubygems-update-1.3.4, rubygems-update-1.3.1, rubygems-update-1.2.0, > > rubygems-update-1.0.1, rubyjs-0.8.0, rubypants-0.2.0, > > rubyscript2exe-0.5.3, rubyzip-0.9.4, rubyzip2-2.0.1, rvm-0.0.59, > > s3sync-1.2.5, sanitize-1.1.0, sequel-3.9.0, session-3.1.0, > > sexp_processor-3.0.3, sexp_processor-3.0.1, shoulda-2.11.3, > > sinatra-1.2.6, sinatra-1.0, sinatra-0.9.4, sinatra-0.9.1.1, > > sinatra_warden-0.2.0.2, slim_scrooge-1.0.5, sqlite3-1.3.3, sqlite3- > > ruby-1.3.3, sqlite3-ruby-1.2.5, stemmer-1.0.1, supermodel-0.1.0, > > syntax-1.0.0, templater-1.0.0, tenjin-0.6.1, term-ansicolor-1.0.5, > > term-ansicolor-1.0.4, term-ansicolor-1.0.3, termios-0.9.4, test- > > unit-2.0.3, test-unit-2.0.2, text-format-1.0.0, text-hyphen-1.0.0, > > thin-1.2.11, thor-0.14.6, thor-0.13.3, tilt-1.3, tilt-0.8, tilt-0.5, > > tilt-0.3, tracepoint-1.1, treetop-1.4.8, treetop-1.4.2, treetop-1.2.4, > > trollop-1.16.2, turn-0.8.1, tzinfo-0.3.24, tzinfo-0.3.16, > > unroller-1.0.0, url_mount-0.2.1, usher-0.8.3, uuid-2.0.2, uuid-2.0.1, > > uuidtools-2.0.0, uuidtools-1.0.7, uuidtools-1.0.3, vclog-1.6.0, > > warden-1.0.3, warden-0.10.2, watchr-0.7, wedge-0.0.1, > > will_paginate-2.3.12, wirble-0.1.3, wirble-0.1.2, wx_sugar-0.1.22, > > wxruby-2.0.0-x86_64-linux, xattr-0.1, xcb-0.0.1, xdg-0.5.2, xdg-0.5.1, > > xdg-0.4.0, xml-simple-1.0.12] > > > > I think I could have managed with just "Could not find rdoc (~> 3)". > > _______________________________________________ > > Rubygems-developers mailing list > > http://rubyforge.org/projects/rubygems > > Rubygems-developers at rubyforge.org (mailto:Rubygems-developers at rubyforge.org) > > http://rubyforge.org/mailman/listinfo/rubygems-developers > > _______________________________________________ > Rubygems-developers mailing list > http://rubyforge.org/projects/rubygems > Rubygems-developers at rubyforge.org (mailto:Rubygems-developers at rubyforge.org) > http://rubyforge.org/mailman/listinfo/rubygems-developers From conery at cs.uoregon.edu Tue Jun 14 16:25:00 2011 From: conery at cs.uoregon.edu (Conery John) Date: Tue, 14 Jun 2011 13:25:00 -0700 Subject: [Rubygems-developers] --test option removed from check command? Message-ID: Hi -- I'm trying to use the "gem check" command to run unit tests for an installed gem. On one of my systems (OS X, running gem 1.8.5) I noticed that the --test option is no longer supported for the check command. Was it removed on purpose? Is there another way I can let users run unit tests after they have installed a gem? Or is there a better way for users to test their gems? Thanks?. John Conery From noreply at rubyforge.org Tue Jun 14 19:41:46 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 14 Jun 2011 19:41:46 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-28713 ] clean and remove should run in reverse topo sort Message-ID: <20110614234146.DB8421858377@rubyforge.org> Bugs item #28713, was opened at 2010-11-12 13:46 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28713&group_id=126 Category: `gem` commands (other) Group: None >Status: Closed Resolution: Accepted Priority: 3 Submitted By: Ryan Davis (zenspider) Assigned to: Ryan Davis (zenspider) Summary: clean and remove should run in reverse topo sort Initial Comment: kiss my ass rubyforge. see summary. ---------------------------------------------------------------------- >Comment By: Ryan Davis (zenspider) Date: 2011-06-14 16:41 Message: moved: https://github.com/rubygems/rubygems/issues/112 ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-06-07 16:50 Message: Hi! Believe it or not, we're moving to github's issue tracker! The pressure to move has been loud and clear, but for the longest time it didn't support the way we worked. Now that it has freeform labels it can support our workflow adequately. There is just one problem: Your bug is here and we don't want to lose you! What we'd like you to do is fairly painless and should only take a few minutes: Please file the _exact_ same ticket on github and provide a link back to this crufty old ticket so we can refer to any previous discussion that occurred. Once the new ticket is made, put a forwarding link to it here and close this ticket out. In a couple weeks, we'll track down the old tickets that are still open and decide what to do with them. We could have done this fairly automatically, but we really want you to do it so you're attached to the ticket and we can still communicate with you and keep a record of it. https://github.com/rubygems/rubygems/issues Thanks, The RubyGems Team ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28713&group_id=126 From noreply at rubyforge.org Tue Jun 14 19:42:30 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 14 Jun 2011 19:42:30 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-28902 ] Specification#ruby_code should be more secure with arrays Message-ID: <20110614234230.23C85185838A@rubyforge.org> Bugs item #28902, was opened at 2011-02-01 20:12 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28902&group_id=126 Category: None Group: None >Status: Closed Resolution: None Priority: 3 Submitted By: Ryan Davis (zenspider) Assigned to: Ryan Davis (zenspider) Summary: Specification#ruby_code should be more secure with arrays Initial Comment: Either check that everything within is clean, or recurse on each member. ---------------------------------------------------------------------- >Comment By: Ryan Davis (zenspider) Date: 2011-06-14 16:42 Message: Moved: https://github.com/rubygems/rubygems/issues/113 ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-06-07 16:50 Message: Hi! Believe it or not, we're moving to github's issue tracker! The pressure to move has been loud and clear, but for the longest time it didn't support the way we worked. Now that it has freeform labels it can support our workflow adequately. There is just one problem: Your bug is here and we don't want to lose you! What we'd like you to do is fairly painless and should only take a few minutes: Please file the _exact_ same ticket on github and provide a link back to this crufty old ticket so we can refer to any previous discussion that occurred. Once the new ticket is made, put a forwarding link to it here and close this ticket out. In a couple weeks, we'll track down the old tickets that are still open and decide what to do with them. We could have done this fairly automatically, but we really want you to do it so you're attached to the ticket and we can still communicate with you and keep a record of it. https://github.com/rubygems/rubygems/issues Thanks, The RubyGems Team ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28902&group_id=126 From noreply at rubyforge.org Tue Jun 14 19:43:27 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 14 Jun 2011 19:43:27 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29258 ] GEM_HOME=xxx gem install rake installs doco wrong Message-ID: <20110614234327.D8C2A185838A@rubyforge.org> Bugs item #29258, was opened at 2011-06-06 16:10 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29258&group_id=126 Category: `gem install` command Group: None >Status: Closed Resolution: None Priority: 3 Submitted By: Ryan Davis (zenspider) Assigned to: Eric Hodel (drbrain) Summary: GEM_HOME=xxx gem install rake installs doco wrong Initial Comment: % l xxx/gems/rake-0.8.7/xxx/doc/rake-0.8.7/ total 0 0 rdoc/ 0 ri/ ---------------------------------------------------------------------- >Comment By: Ryan Davis (zenspider) Date: 2011-06-14 16:43 Message: Moved: https://github.com/rubygems/rubygems/issues/114 ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-06-07 16:50 Message: Hi! Believe it or not, we're moving to github's issue tracker! The pressure to move has been loud and clear, but for the longest time it didn't support the way we worked. Now that it has freeform labels it can support our workflow adequately. There is just one problem: Your bug is here and we don't want to lose you! What we'd like you to do is fairly painless and should only take a few minutes: Please file the _exact_ same ticket on github and provide a link back to this crufty old ticket so we can refer to any previous discussion that occurred. Once the new ticket is made, put a forwarding link to it here and close this ticket out. In a couple weeks, we'll track down the old tickets that are still open and decide what to do with them. We could have done this fairly automatically, but we really want you to do it so you're attached to the ticket and we can still communicate with you and keep a record of it. https://github.com/rubygems/rubygems/issues Thanks, The RubyGems Team ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29258&group_id=126 From noreply at rubyforge.org Tue Jun 14 19:44:58 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 14 Jun 2011 19:44:58 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29253 ] Gem plugins + gem install -i causes activation errors Message-ID: <20110614234459.05821185838A@rubyforge.org> Bugs item #29253, was opened at 2011-06-04 13:34 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29253&group_id=126 Category: `gem install` command Group: v1.8.x >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Eric Hodel (drbrain) >Assigned to: Ryan Davis (zenspider) Summary: Gem plugins + gem install -i causes activation errors Initial Comment: Steps to reproduce: gem install rubygems-test (has a rake dependency) gem install rake -v 0.8.7 gem install rake gem install -i /tmp/gems rake Expected results: rake installed in /tmp/gems Actual results: ./lib/rubygems/dependency.rb:252:in `to_specs': Could not find rake (>= 0.8.7) amongst [] (Gem::LoadError) from ./lib/rubygems/specification.rb:760:in `find_in_unresolved' from ./lib/rubygems/specification.rb:760:in `map' from ./lib/rubygems/specification.rb:760:in `find_in_unresolved' from ./lib/rubygems/custom_require.rb:43:in `require' from ./lib/rubygems/remote_fetcher.rb:63:in `initialize' from ./lib/rubygems/remote_fetcher.rb:48:in `new' from ./lib/rubygems/remote_fetcher.rb:48:in `fetcher' from ./lib/rubygems/spec_fetcher.rb:66:in `initialize' from ./lib/rubygems/spec_fetcher.rb:43:in `new' from ./lib/rubygems/spec_fetcher.rb:43:in `fetcher' from ./lib/rubygems/dependency_installer.rb:129:in `find_gems_with_sources' from ./lib/rubygems/dependency_installer.rb:269:in `find_spec_by_name_and_version' from ./lib/rubygems/dependency_installer.rb:300:in `install' from ./lib/rubygems/commands/install_command.rb:124:in `execute' from ./lib/rubygems/commands/install_command.rb:118:in `each' from ./lib/rubygems/commands/install_command.rb:118:in `execute' from ./lib/rubygems/command.rb:278:in `invoke' from ./lib/rubygems/command_manager.rb:161:in `process_args' from ./lib/rubygems/command_manager.rb:120:in `run' from ./lib/rubygems/gem_runner.rb:64:in `run' from /usr/bin/gem:21 `gem install -i path` changes the source directory for Gem::Specification so no gems are available. This works with RubyGems 1.7.2 and older, probably due to separate Gem::SourceIndexes for installation of gems and for loading gems. A workaround is to uninstall rubygems-test or uninstall the old version of rake. A possible fix could be to force-resolve dependencies when changing Gem::Specification's source directories ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-06-07 16:50 Message: Hi! Believe it or not, we're moving to github's issue tracker! The pressure to move has been loud and clear, but for the longest time it didn't support the way we worked. Now that it has freeform labels it can support our workflow adequately. There is just one problem: Your bug is here and we don't want to lose you! What we'd like you to do is fairly painless and should only take a few minutes: Please file the _exact_ same ticket on github and provide a link back to this crufty old ticket so we can refer to any previous discussion that occurred. Once the new ticket is made, put a forwarding link to it here and close this ticket out. In a couple weeks, we'll track down the old tickets that are still open and decide what to do with them. We could have done this fairly automatically, but we really want you to do it so you're attached to the ticket and we can still communicate with you and keep a record of it. https://github.com/rubygems/rubygems/issues Thanks, The RubyGems Team ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29253&group_id=126 From noreply at rubyforge.org Tue Jun 14 19:45:54 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 14 Jun 2011 19:45:54 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29266 ] undefined method `name' for " actionmailer" :String Message-ID: <20110614234554.0F4BA185838A@rubyforge.org> Bugs item #29266, was opened at 2011-06-08 23:46 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29266&group_id=126 Category: None Group: None >Status: Closed >Resolution: Rejected Priority: 3 Submitted By: Behrang Saeedzadeh (behrangsa) >Assigned to: Ryan Davis (zenspider) Summary: undefined method `name' for "actionmailer":String Initial Comment: After creating an RoR 2.3.9 using Ruby 1.8.7 I uncommented the following line # config.gem "bj" And then ran rake gems:install. Rake aborted and the following message was printed on the screen: $ rake gems:install (in /Users/Foo/Bar/Baz) rake aborted! undefined method `name' for "actionmailer":String ---------------------------------------------------------------------- Comment By: Luis Lavena (luislavena) Date: 2011-06-09 05:49 Message: Hello, No, according to Aaron Patterson (Rails-Core) to fix that and make Rails use RubyGems 1.8.x API fully will require a complete overhaul of that part of Rails. Rails 3.0.x and 3.x are better candidates for getting that fixed. ---------------------------------------------------------------------- Comment By: Behrang Saeedzadeh (behrangsa) Date: 2011-06-09 05:41 Message: Thanks Ryan. Upgrading to 2.3.12 fixed the problem. But I still get these deprecation messages when I run the server: NOTE: Gem.source_index is deprecated, use Specification. It will be removed on or after 2011-11-01. Gem.source_index called from /Users/behrangsa/.rvm/gems/ruby-1.8.7-p334 at developious/gems/rails-2.3.12/lib/rails/gem_dependency.rb:21. NOTE: Gem::SourceIndex#initialize is deprecated with no replacement. It will be removed on or after 2011-11-01. Gem::SourceIndex#initialize called from /Users/behrangsa/.rvm/gems/ruby-1.8.7-p334 at developious/gems/rails- 2.3.12/lib/rails/vendor_gem_source_index.rb:100. Is there a way to fix/hide these messages? Cheers, Behrang ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-06-09 03:52 Message: This is a bug in rails. The fix was just released in 2.3.12. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29266&group_id=126 From noreply at rubyforge.org Tue Jun 14 20:27:02 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 14 Jun 2011 20:27:02 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29198 ] gem rdoc uses some deprecated methods Message-ID: <20110615002702.F42001858377@rubyforge.org> Bugs item #29198, was opened at 2011-05-10 16:56 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29198&group_id=126 Category: `gem` commands (other) Group: None >Status: Closed Resolution: None Priority: 3 Submitted By: Roger Pack (rogerdpack) Assigned to: Ryan Davis (zenspider) Summary: gem rdoc uses some deprecated methods Initial Comment: running $ gem rdoc flickraw with 1.8.1 shows lots of deprecation warnings, which was a bit unexpected. Cheers! ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-06-07 16:50 Message: Hi! Believe it or not, we're moving to github's issue tracker! The pressure to move has been loud and clear, but for the longest time it didn't support the way we worked. Now that it has freeform labels it can support our workflow adequately. There is just one problem: Your bug is here and we don't want to lose you! What we'd like you to do is fairly painless and should only take a few minutes: Please file the _exact_ same ticket on github and provide a link back to this crufty old ticket so we can refer to any previous discussion that occurred. Once the new ticket is made, put a forwarding link to it here and close this ticket out. In a couple weeks, we'll track down the old tickets that are still open and decide what to do with them. We could have done this fairly automatically, but we really want you to do it so you're attached to the ticket and we can still communicate with you and keep a record of it. https://github.com/rubygems/rubygems/issues Thanks, The RubyGems Team ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29198&group_id=126 From noreply at rubyforge.org Tue Jun 14 20:27:57 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 14 Jun 2011 20:27:57 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-27975 ] " gemspec is valid" has different meaning locally versus at submit time. Message-ID: <20110615002757.0F410185838A@rubyforge.org> Bugs item #27975, was opened at 2010-03-16 09:49 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27975&group_id=126 Category: None Group: v1.3.x >Status: Closed Resolution: Accepted Priority: 3 Submitted By: Roger Pack (rogerdpack) Assigned to: Nick Quaranto (qrush) Summary: "gemspec is valid" has different meaning locally versus at submit time. Initial Comment: Currently the gemspec validity check doesn't check for a valid url (if there is one), however gemcutter does, so there's some surprisingness when your gemspec "is valid" but then later "is no longer valid" when you go to submit it. suggestion: have the validity check check for valid url to avoid this surprisingness. Thanks. -r ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-06-07 16:50 Message: Hi! Believe it or not, we're moving to github's issue tracker! The pressure to move has been loud and clear, but for the longest time it didn't support the way we worked. Now that it has freeform labels it can support our workflow adequately. There is just one problem: Your bug is here and we don't want to lose you! What we'd like you to do is fairly painless and should only take a few minutes: Please file the _exact_ same ticket on github and provide a link back to this crufty old ticket so we can refer to any previous discussion that occurred. Once the new ticket is made, put a forwarding link to it here and close this ticket out. In a couple weeks, we'll track down the old tickets that are still open and decide what to do with them. We could have done this fairly automatically, but we really want you to do it so you're attached to the ticket and we can still communicate with you and keep a record of it. https://github.com/rubygems/rubygems/issues Thanks, The RubyGems Team ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27975&group_id=126 From luislavena at gmail.com Tue Jun 14 20:41:02 2011 From: luislavena at gmail.com (Luis Lavena) Date: Tue, 14 Jun 2011 21:41:02 -0300 Subject: [Rubygems-developers] --test option removed from check command? In-Reply-To: References: Message-ID: On Tue, Jun 14, 2011 at 5:25 PM, Conery John wrote: > Hi -- > > I'm trying to use the "gem check" command to run unit tests for an installed gem. ?On one of my systems (OS X, running gem 1.8.5) I noticed that the --test option is no longer supported for the check command. ?Was it removed on purpose? ?Is there another way I can let users run unit tests after they have installed a gem? ?Or is there a better way for users to test their gems? > Testing of RubyGems has been removed (deprecated) and replaced by a better testing infrastructure in a RubyGems plugin: gem install rubygems-test: https://github.com/rubygems/rubygems-test -- 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 conery at cs.uoregon.edu Wed Jun 15 16:22:05 2011 From: conery at cs.uoregon.edu (Conery John) Date: Wed, 15 Jun 2011 13:22:05 -0700 Subject: [Rubygems-developers] --test option removed from check command? In-Reply-To: References: Message-ID: Ah, thanks, Luis, I figured it must be something like this. FWIW, my two cents: This change makes perfect sense for most Ruby users, but it will be a minor irritant for me -- I wrote some Ruby code for students to install, and I'd like to minimize the number of things they need to download to set up their environment. In this case I have an easy workaround, though. I have them run a setup script after installing my gem, and I can just modify this script so it does the unit tests. Thanks again -- I appreciate all you and the others have been doing with gem, the Windows installer, etc. JC On Jun 14, 2011, at 5:41 PM, Luis Lavena wrote: > On Tue, Jun 14, 2011 at 5:25 PM, Conery John wrote: >> Hi -- >> >> I'm trying to use the "gem check" command to run unit tests for an installed gem. On one of my systems (OS X, running gem 1.8.5) I noticed that the --test option is no longer supported for the check command. Was it removed on purpose? Is there another way I can let users run unit tests after they have installed a gem? Or is there a better way for users to test their gems? >> > > Testing of RubyGems has been removed (deprecated) and replaced by a > better testing infrastructure in a RubyGems plugin: gem install > rubygems-test: > > https://github.com/rubygems/rubygems-test > > -- > Luis Lavena > AREA 17 > - > Perfection in design is achieved not when there is nothing more to add, > but rather when there is nothing more to take away. > Antoine de Saint-Exup?ry > _______________________________________________ > Rubygems-developers mailing list > http://rubyforge.org/projects/rubygems > Rubygems-developers at rubyforge.org > http://rubyforge.org/mailman/listinfo/rubygems-developers From drbrain at segment7.net Wed Jun 15 18:08:34 2011 From: drbrain at segment7.net (Eric Hodel) Date: Wed, 15 Jun 2011 15:08:34 -0700 Subject: [Rubygems-developers] --test option removed from check command? In-Reply-To: References: Message-ID: On Jun 15, 2011, at 1:22 PM, Conery John wrote: > FWIW, my two cents: This change makes perfect sense for most Ruby users, but it will be a minor irritant for me -- I wrote some Ruby code for students to install, and I'd like to minimize the number of things they need to download to set up their environment. In this case I have an easy workaround, though. I have them run a setup script after installing my gem, and I can just modify this script so it does the unit tests. Unfortunately the --test code had been unmaintained for so long it barely worked. Moving it out of RubyGems allowed Erik Hollensbe to do an excellent job on it since he had the time, willingness, and ability to quickly release new versions with improvements and bug fixes. From erik at hollensbe.org Wed Jun 15 18:51:43 2011 From: erik at hollensbe.org (Erik Hollensbe) Date: Wed, 15 Jun 2011 18:51:43 -0400 Subject: [Rubygems-developers] --test option removed from check command? In-Reply-To: References: Message-ID: <78ED60D7-4E83-4300-A368-94B854EA994A@hollensbe.org> On Jun 15, 2011, at 6:08 PM, Eric Hodel wrote: > On Jun 15, 2011, at 1:22 PM, Conery John wrote: >> FWIW, my two cents: This change makes perfect sense for most Ruby users, but it will be a minor irritant for me -- I wrote some Ruby code for students to install, and I'd like to minimize the number of things they need to download to set up their environment. In this case I have an easy workaround, though. I have them run a setup script after installing my gem, and I can just modify this script so it does the unit tests. > > Unfortunately the --test code had been unmaintained for so long it barely worked. Moving it out of RubyGems allowed Erik Hollensbe to do an excellent job on it since he had the time, willingness, and ability to quickly release new versions with improvements and bug fixes. I'm happy to help anyone resolve issues with rubygems-test either here, as appropriate, or on the tracker at github (see luis's email for the link). I think you'll find integration with most gems fairly straightforward, but I'm a bit biased. :) -Erik From noreply at rubyforge.org Tue Jun 21 19:18:09 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 21 Jun 2011 19:18:09 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-14943 ] rubygems should use the same arch specific subdirs in lib for the native extensions as ruby Message-ID: <20110621231810.1A0C01858378@rubyforge.org> Bugs item #14943, was opened at 2007-10-22 03:57 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=14943&group_id=126 Category: RubyGems installer (setup.rb) Group: v0.9.5 >Status: Closed >Resolution: Out of Date Priority: 1 Submitted By: Marcus Rueckert (darix) Assigned to: Eric Hodel (drbrain) Summary: rubygems should use the same arch specific subdirs in lib for the native extensions as ruby Initial Comment: quoting my my mail to ruby-core [1] [[[ there is another feature that gem doesnt handle nicely atm: with the standard ruby directory layout you can share the tree via nfs for multiple architectures as the native extensions are in an arch specific path. within an installed gem they are directly inside the "lib" subdir. i wonder if gem should use the arch specific subdirs below its "lib" subdir aswell. ]]] Eric asked me in a follow up to open a ticket here. :) Looking forward to the fix :) [1] http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/12724 ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-06-21 16:18 Message: I'm closing this ticket as we've moved to github issues for all issue tracking. Please refile this ticket there if you think it is still valid. https://github.com/rubygems/rubygems/issues Thanks, The RubyGems Team ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-06-07 16:50 Message: Hi! Believe it or not, we're moving to github's issue tracker! The pressure to move has been loud and clear, but for the longest time it didn't support the way we worked. Now that it has freeform labels it can support our workflow adequately. There is just one problem: Your bug is here and we don't want to lose you! What we'd like you to do is fairly painless and should only take a few minutes: Please file the _exact_ same ticket on github and provide a link back to this crufty old ticket so we can refer to any previous discussion that occurred. Once the new ticket is made, put a forwarding link to it here and close this ticket out. In a couple weeks, we'll track down the old tickets that are still open and decide what to do with them. We could have done this fairly automatically, but we really want you to do it so you're attached to the ticket and we can still communicate with you and keep a record of it. https://github.com/rubygems/rubygems/issues Thanks, The RubyGems Team ---------------------------------------------------------------------- Comment By: James Tucker (raggi) Date: 2010-11-26 15:25 Message: VERSION should include prefix, suffix and full version. RubyCores idea that the contents of 1.9.1 are compatible with 1.9.x is a completely invalid assumption. I spoke to Matz about this at RubyConf. He suggested we speak to nobu. ---------------------------------------------------------------------- Comment By: Marcus Rueckert (darix) Date: 2010-11-25 11:59 Message: would be an option. but then you still need 2 search paths: 1. for pure ruby gems 2. one for gems with native portions. i just want consistent behavior, especially now that rubygems is in the core. although the $(Gem.dir)/gems/foo-1.0/lib/ method had the advantage for me that i could share the pure ruby stuff between all archs in my packages. but the other way would work for me aswell. ---------------------------------------------------------------------- Comment By: Luis Lavena (luislavena) Date: 2010-11-25 10:49 Message: Hello Marcus, There has been several conversations about the pollution of LOAD_PATH and a proposal of solution by Eric Hodel at ruby-core: http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/33206 I think making RubyGems add another PATH inside the same gem will be a problem. Instead, what if the default path where gems are installed contains the platform information? So Gem.dir and Gem.path uses ~/.gem/ENGINE/VERSION/PLATFORM Where ENGINE is ruby/jruby VERSION is 1.8 or 1.9.1 and PLATFORM is the one computed by Gem::Platform.local That will not solve the coexistence of the same codebase for two different platforms, but at least will avoid having another performance discussion at Ruby-Core Thoughts? ---------------------------------------------------------------------- Comment By: Marcus Rueckert (darix) Date: 2010-11-25 10:32 Message: 1. i think this ticket is still very valid. 2. i didnt mean that gems should be able to describe native libraries. while it would be nice it is not in the scope of this bug, so it should mostlikely be tracked in a different bug. If you open it, please CC me. I am sure i can give some tips and tricks how we solve it in the linux packaging world to achieve better cross distro support. ---------------------------------------------------------------------- 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: Hongli Lai (hongli) Date: 2010-01-20 14:37 Message: My experience with package management (Dev-C++, Autopackage, Phusion Passenger) so far is that dependency rules, especially for cross-platform software, can get very complex. I'm not sure whether it's at all possible to cover all cases without a turing-complete dependency specification language. Autopackage's dependency checking mechanism is turing-complete (shell scripts) and it works wonderfully well, though few people understand it because it's so powerful. But maybe it's possible to have a "good enough" system that works for most people, and let developers who need more power write their own thing, kinda like what we did for Phusion Passenger by splitting native dependency checking to passenger-install-*-module. For DebGem we didn't try to make RubyGems support native dependencies. We just manually maintained a per-gem native dependency list. I agree with not bothering with C++ compatibility. Most native extensions are written in C anyways. Developers can always write their own thing to handle this. For example the next version of Phusion Passenger will no longer specify extconf.rb in the gem spec; instead it will automatically compile the native extension when it's require()'ed into an Ruby version-, OS- and architecture-specific subdirectory under $HOME. As for Rubists being pitiful at dependency management: most Rubyists are on OS X which has no proper dependency management, so most people are not only unfamiliar with native dependency management but also wouldn't benefit from it. :) If RubyGems is to support native dependencies it should make it extremely easy for gem writers to specify them correctly. ---------------------------------------------------------------------- Comment By: James Tucker (raggi) Date: 2010-01-20 10:33 Message: I mean, whilst GCC versions might be ok for C++, what about say, a lua plugin or a php plugin, etc, etc. Tracking external dependencies and binary level compatibility becomes a nightmare with more VMs / runtimes, combined too with platforms, heh. Maybe, if we could pull in a more advanced extconf, that allowed arbitrary addition of dependency information, by reasonably formed keys, maybe such as: dependencies << [:debian, :package, :gcc, gcc_version] dependencies << [:debian, :package, :lua, lua_version] etc Then compute that based on some hash of the total dependency set (merged with rubys). So then you have a ruby dependency hash, from rbconfig (plus expanded info), and a gem dependency hash from install-time expansion data. I've actually missed something here, which is to tell the dependencies list how to check if those dependencies are still available... Need to store some code for that really, so eval strings (nominally probably calls to Kernel#`)... ---------------------------------------------------------------------- Comment By: James Tucker (raggi) Date: 2010-01-20 10:28 Message: Hongli Lai - agreed completely. A hash of some larger set of attributes may be most appropriate. As far as dependencies like C++ are concerned, there's little we can do to be complete in that area. I try to encourage a move toward proper dependency management, but rubyists are extremely pitiful at this traditionally. ---------------------------------------------------------------------- Comment By: James Tucker (raggi) Date: 2010-01-20 10:26 Message: I support the idea of putting a gem in an arch specific subdir. I am strongly against this subdir being inside the gems installed path. 1. some platform specific gems pack different *ruby* code in their gemfiles for specific archs 2. some gems do not use the commonly accepted paths, or have multiple lib paths, i wouldn't want selection of the path to become arbitrary ---------------------------------------------------------------------- Comment By: Hongli Lai (hongli) Date: 2010-01-20 08:27 Message: I support this change. This would make it possible for multiple Ruby interpreters, possibly on multiple machines with different platforms, to share the same gem directory. However I don't think Gem::Platform in its current form is adequate. While Gem::Platform is a good enough description of the platform, it isn't a good enough description of Ruby extension binary compatibility, which is what matters more. A few examples: - OS X Snow Leopard broke the ABI by switching to x86_64 by default, but uname and therefore RUBY_PLATFORM still report i386 as platform. - Ruby breaks API compatibility even between teeny releases, e.g. RSTRING_PTR vs RSTRING(x)->ptr. The former didn't exist until 1.8.6. On 1.8.7 and later it became required so that the latter doesn't work anymore. It doesn't look like the ABI changes but the Ruby core team doesn't seem to make any ABI guarantees. The switch from 1.8 to 1.9 most definitely breaks some ABI though. For Phusion Passenger we use the following code to identify Ruby extension binary compatibility: http://pastie.org/786648 But even this doesn't tell us the entire story. For example it doesn't include the C++ ABI version, which can be a problem for Ruby extensions written in C++ like EventMachine. GCC breaks the C++ ABI regularly, sometimes even multiple times within the same minor release. For example GCC 3.1 broke the C++ ABI about 3 times if I recall correctly. ---------------------------------------------------------------------- Comment By: Daniel Berger (djberg96) Date: 2009-02-01 20:56 Message: Luis, Right, modification to the extension builder would be required as far as I know. Dan ---------------------------------------------------------------------- Comment By: Luis Lavena (luislavena) Date: 2009-01-31 05:03 Message: Sorry not to properly introduce my question. Let's say I build a gem with VC6 (i386-mswin32), the gem platform is x86-mswin32-60 This means, my lib folder will be like this: lib/my_lib.rb lib/x86-mswin32-60/my_ext.so my_lib.rb contains this: require 'my_ext' now, I'm in a IRB session: require 'rubygems' require 'my_lib' It is supposed to work out. But what about this: require 'rubygems' require 'my_ext' Right now, since lib is added to LOAD_PATH on gem activation, there is no problem with that. With the change, it indicates that: If a gem contains a platform folder for libdir and the platform matches the current one, it should append that folder into LOAD_PATH. That is the correct assumption? I believe changes to Extension Builders bundled in rubygems will be required. ---------------------------------------------------------------------- Comment By: Daniel Berger (djberg96) Date: 2009-01-27 09:52 Message: Luis, I'm not sure what you mean by "require of the extension directly". Can you explain? Dan ---------------------------------------------------------------------- Comment By: Luis Lavena (luislavena) Date: 2009-01-27 09:01 Message: So this will mean "lib/#{Gem::Platform}" will be added to the $LOAD_PATH if exist, correct? What happens when users doing the require of the extension directly? it triggers the activation mechanism? I kind of like this, but maybe I'm missing a drawback that will against us in the long run? ---------------------------------------------------------------------- Comment By: Daniel Berger (djberg96) Date: 2009-01-26 12:24 Message: For example, if you install a C extension gem called 'foo' on Windows you want it to install as: C:/ruby/lib/ruby/gems/1.8/gems/foo/lib/i386-msvcr80/foo.so And Rubygems should add this sitearch directory to its search path? Is that about the sum of it? Regards, Dan ---------------------------------------------------------------------- Comment By: 7rans (transami) Date: 2007-11-06 02:27 Message: After some trial and error with extensions, I m starting to agree with this. It's more flexible. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=14943&group_id=126 From noreply at rubyforge.org Tue Jun 21 19:18:10 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 21 Jun 2011 19:18:10 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-28414 ] RubyGems 1.3.7 default gem directory is wrong when used with ruby 1.9.1 with --program-suffix=1.9 Message-ID: <20110621231810.41D92185838A@rubyforge.org> Bugs item #28414, was opened at 2010-07-22 05:44 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28414&group_id=126 Category: `gem` commands (other) Group: v1.3.x >Status: Closed >Resolution: Out of Date Priority: 3 Submitted By: Svetoslav Agafonkin (svetlyo) Assigned to: Eric Hodel (drbrain) Summary: RubyGems 1.3.7 default gem directory is wrong when used with ruby 1.9.1 with --program-suffix=1.9 Initial Comment: RubyGems 1.3.7 default gem directory is wrong when used with ruby 1.9.1 with --program-suffix=1.9. Gem.default_dir generates "/opt/local/lib/ruby/gems/1.9.1/" instead of "/opt/local/lib/ruby1.9/gems/1.9.1/". The change was introduced in lib/rubygems/defaults.rb in http://github.com/rubygems/rubygems/commit/0495c7c0dd9878f9a7a74f5133d7892d28d01812 - a big import from the ruby trunk, right after 1.3.6 was released. The original change comes from this commit: http://redmine.ruby-lang.org/repositories/diff/ruby-19?rev=26048 --------------------- Mac OS X 10.5.8 ruby 1.9.1_429 (from Macports) rubgygems 1.3.7 $ gem1.9 env RubyGems Environment: - RUBYGEMS VERSION: 1.3.7 - RUBY VERSION: 1.9.1 (2010-07-02 patchlevel 429) [i386-darwin9] - INSTALLATION DIRECTORY: /opt/local/lib/ruby/gems/1.9.1 - RUBY EXECUTABLE: /opt/local/bin/ruby1.9 - EXECUTABLE DIRECTORY: /opt/local/bin - RUBYGEMS PLATFORMS: - ruby - x86-darwin-9 - GEM PATHS: - /opt/local/lib/ruby/gems/1.9.1 - /Users/fro/.gem/ruby/1.9.1 - GEM CONFIGURATION: - :update_sources => true - :verbose => true - :benchmark => false - :backtrace => false - :bulk_threshold => 1000 - REMOTE SOURCES: - http://rubygems.org/ ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-06-21 16:18 Message: I'm closing this ticket as we've moved to github issues for all issue tracking. Please refile this ticket there if you think it is still valid. https://github.com/rubygems/rubygems/issues Thanks, The RubyGems Team ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-06-07 16:50 Message: Hi! Believe it or not, we're moving to github's issue tracker! The pressure to move has been loud and clear, but for the longest time it didn't support the way we worked. Now that it has freeform labels it can support our workflow adequately. There is just one problem: Your bug is here and we don't want to lose you! What we'd like you to do is fairly painless and should only take a few minutes: Please file the _exact_ same ticket on github and provide a link back to this crufty old ticket so we can refer to any previous discussion that occurred. Once the new ticket is made, put a forwarding link to it here and close this ticket out. In a couple weeks, we'll track down the old tickets that are still open and decide what to do with them. We could have done this fairly automatically, but we really want you to do it so you're attached to the ticket and we can still communicate with you and keep a record of it. https://github.com/rubygems/rubygems/issues Thanks, The RubyGems Team ---------------------------------------------------------------------- Comment By: James Tucker (raggi) Date: 2010-11-13 08:20 Message: This is also related to a ruby bug that I need to submit. Feel free to assign to me after the we decide what to do with the suffix. ---------------------------------------------------------------------- Comment By: John Barnette (jbarnette) Date: 2010-11-13 05:44 Message: Eric, what do you think? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28414&group_id=126 From noreply at rubyforge.org Tue Jun 21 19:18:10 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 21 Jun 2011 19:18:10 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-28742 ] Manual states gemrc is looked up in home directory only whereas /etc/gemrc is also consulted Message-ID: <20110621231810.504AB1858376@rubyforge.org> Bugs item #28742, was opened at 2010-11-22 09:02 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28742&group_id=126 Category: documentation Group: v1.3.x >Status: Closed >Resolution: Out of Date Priority: 3 Submitted By: Rich Meyers (richmeyers) Assigned to: Eric Hodel (drbrain) Summary: Manual states gemrc is looked up in home directory only whereas /etc/gemrc is also consulted Initial Comment: Documentation here: http://docs.rubygems.org/read/chapter/11 states: gem looks for a configuration file .gemrc in your home directory, although you can specify another file on the command-line if you wish (with the ?config-file modifier). Only one configuration file will be processed: the rightmost one on the command-line, or the default $HOME/.gemrc, or none at all. In actuality, configuration may be taken from /etc/gemrc if it exists. RubyGems Environment: - RUBYGEMS VERSION: 1.3.7 - RUBY VERSION: 1.8.7 (2009-12-24 patchlevel 248) [amd64-freebsd8] - INSTALLATION DIRECTORY: /usr/local/lib/ruby/gems/1.8 - RUBY EXECUTABLE: /usr/local/bin/ruby18 - EXECUTABLE DIRECTORY: /usr/local/bin - RUBYGEMS PLATFORMS: - ruby - amd64-freebsd-8 - GEM PATHS: - /usr/local/lib/ruby/gems/1.8 - /home/rm/.gem/ruby/1.8 - GEM CONFIGURATION: - :update_sources => true - :verbose => true - :benchmark => false - :backtrace => false - :bulk_threshold => 1000 - REMOTE SOURCES: - http://gems.rubyforge.org ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-06-21 16:18 Message: I'm closing this ticket as we've moved to github issues for all issue tracking. Please refile this ticket there if you think it is still valid. https://github.com/rubygems/rubygems/issues Thanks, The RubyGems Team ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-06-07 16:50 Message: Hi! Believe it or not, we're moving to github's issue tracker! The pressure to move has been loud and clear, but for the longest time it didn't support the way we worked. Now that it has freeform labels it can support our workflow adequately. There is just one problem: Your bug is here and we don't want to lose you! What we'd like you to do is fairly painless and should only take a few minutes: Please file the _exact_ same ticket on github and provide a link back to this crufty old ticket so we can refer to any previous discussion that occurred. Once the new ticket is made, put a forwarding link to it here and close this ticket out. In a couple weeks, we'll track down the old tickets that are still open and decide what to do with them. We could have done this fairly automatically, but we really want you to do it so you're attached to the ticket and we can still communicate with you and keep a record of it. https://github.com/rubygems/rubygems/issues Thanks, The RubyGems Team ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28742&group_id=126 From noreply at rubyforge.org Tue Jun 21 19:18:10 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 21 Jun 2011 19:18:10 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-28844 ] rubygems plugins, 1.9 and circular requires Message-ID: <20110621231810.8251418583A4@rubyforge.org> Bugs item #28844, was opened at 2011-01-09 17:24 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28844&group_id=126 Category: #gem and #require methods Group: v1.3.x >Status: Closed >Resolution: Out of Date Priority: 3 Submitted By: Erik Hollensbe (erikh) Assigned to: Eric Hodel (drbrain) Summary: rubygems plugins, 1.9 and circular requires Initial Comment: I apologize in advance if this is confusing. I'm not entirely sure if this is gem_prelude's fault or rubygems's or even ruby proper's fault, but here goes: http://www.gem-testers.org/gems/rubygems-test/v/0.2.1/test_results/2 If you carefully examine the stack trace, you'll see that the rdoc plugin is being pulled in, then hanna is being pulled in. What happens in hanna is that rubygems is pulled in, ergo our problem. This is all done in from a rake process spawned by rubygems-test which uses open4 which in 1.9 uses threads, so threading may be a part of the issue here. This issue does not exhibit in 1.8, but it uses fork there. I was unable to test in RG 1.4 because of the obvious. I was able to fix this in rubygems-test 0.2.1 for the 'gem test' provider. The commit below is the fix. https://github.com/rubygems/rubygems-test/commit/72b0e136889fcd2509bb040de3fe9220c4b8bc13 You can see that I abuse autoload there to ensure that any rubygems dependencies (and YAML to be safe) are only loaded once. This is because of the above issue. These patches fix it but not for rdoc and (I presume) other plugins. What probably needs to happen is some beyond-the-call-of-duty $:/$" inspection before plugin load runs or to somehow load plugins with autoload (I don't think this is possible though). Obviously I'm deferring to your experience. Please feel free to tell me where to stick this bug report if it does not belong here, I'm just convinced after the discrete repros that it at least gets close to starting in rubygems. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-06-21 16:18 Message: I'm closing this ticket as we've moved to github issues for all issue tracking. Please refile this ticket there if you think it is still valid. https://github.com/rubygems/rubygems/issues Thanks, The RubyGems Team ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-06-07 16:50 Message: Hi! Believe it or not, we're moving to github's issue tracker! The pressure to move has been loud and clear, but for the longest time it didn't support the way we worked. Now that it has freeform labels it can support our workflow adequately. There is just one problem: Your bug is here and we don't want to lose you! What we'd like you to do is fairly painless and should only take a few minutes: Please file the _exact_ same ticket on github and provide a link back to this crufty old ticket so we can refer to any previous discussion that occurred. Once the new ticket is made, put a forwarding link to it here and close this ticket out. In a couple weeks, we'll track down the old tickets that are still open and decide what to do with them. We could have done this fairly automatically, but we really want you to do it so you're attached to the ticket and we can still communicate with you and keep a record of it. https://github.com/rubygems/rubygems/issues Thanks, The RubyGems Team ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28844&group_id=126 From noreply at rubyforge.org Tue Jun 21 19:18:10 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 21 Jun 2011 19:18:10 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-28889 ] gem rdoc --all --overwrite doesn't work Message-ID: <20110621231810.99E14167835C@rubyforge.org> Bugs item #28889, was opened at 2011-01-28 12:07 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28889&group_id=126 Category: None Group: None >Status: Closed >Resolution: Out of Date Priority: 3 Submitted By: V?t Ondruch (voxik) Assigned to: Eric Hodel (drbrain) Summary: gem rdoc --all --overwrite doesn't work Initial Comment: C:\>gem rdoc --all --overwrite Installing ri documentation for bundler-1.0.9... Installing ri documentation for minitest-2.0.2... ERROR: While executing gem ... (Errno::ENOENT) No such file or directory - C:/Users/vita/.pik/rubies/Ruby-193-dev/lib/ruby/gems/1.9.1/gems/minitest-2.0.2 It is apparently one of the bundled gems, therefore the directory cannot be found. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-06-21 16:18 Message: I'm closing this ticket as we've moved to github issues for all issue tracking. Please refile this ticket there if you think it is still valid. https://github.com/rubygems/rubygems/issues Thanks, The RubyGems Team ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-06-07 16:50 Message: Hi! Believe it or not, we're moving to github's issue tracker! The pressure to move has been loud and clear, but for the longest time it didn't support the way we worked. Now that it has freeform labels it can support our workflow adequately. There is just one problem: Your bug is here and we don't want to lose you! What we'd like you to do is fairly painless and should only take a few minutes: Please file the _exact_ same ticket on github and provide a link back to this crufty old ticket so we can refer to any previous discussion that occurred. Once the new ticket is made, put a forwarding link to it here and close this ticket out. In a couple weeks, we'll track down the old tickets that are still open and decide what to do with them. We could have done this fairly automatically, but we really want you to do it so you're attached to the ticket and we can still communicate with you and keep a record of it. https://github.com/rubygems/rubygems/issues Thanks, The RubyGems Team ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28889&group_id=126 From noreply at rubyforge.org Tue Jun 21 19:18:10 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 21 Jun 2011 19:18:10 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-28935 ] Failing rdoc generation doesnt fail the installation since 1.5 Message-ID: <20110621231810.B2D1F1598071@rubyforge.org> Bugs item #28935, was opened at 2011-02-17 11:16 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28935&group_id=126 Category: `gem install` command Group: None >Status: Closed >Resolution: Out of Date Priority: 3 Submitted By: Marcus Rueckert (darix) Assigned to: Eric Hodel (drbrain) Summary: Failing rdoc generation doesnt fail the installation since 1.5 Initial Comment: it seems gem install returns 0, even though the rdoc generation failed. in 1.3.7 it still returned the a non zero return code. as shown here http://bit.ly/f8vfi7 e.g. important part: [[[ 1 gem installed Installing ri documentation for ci_reporter-1.6.4... rdoc --ri --op /var/tmp/rubygem-ci_reporter-1.6.4-build/usr/lib64/ruby/gems/1.8/doc/ci_reporter-1.6.4/ri --main README.txt -SHN -f darkfish --quiet lib History.txt Manifest.txt README.txt LICENSE.txt --title ci_reporter-1.6.4 Documentation Installing RDoc documentation for ci_reporter-1.6.4... rdoc --op /var/tmp/rubygem-ci_reporter-1.6.4-build/usr/lib64/ruby/gems/1.8/doc/ci_reporter-1.6.4/rdoc --main README.txt -SHN -f darkfish --quiet lib History.txt Manifest.txt README.txt LICENSE.txt --title ci_reporter-1.6.4 Doc Invalid output formatter For help on options, try 'rdoc --help' ERROR: While generating documentation for ci_reporter-1.6.4 ... MESSAGE: exit ... RDOC args: --op /var/tmp/rubygem-ci_reporter-1.6.4-build/usr/lib64/ruby/gems/1.8/doc/ci_reporter-1.6.4/rdoc --main README.txt -SHN -f darkfish --quiet lib History.txt Manifest.txt README.txt LICENSE.txt --title ci_reporter-1.6.4 Documentation (continuing with the rest of the installation) ]]] the problem in the build was that the ruby version didnt ship the darkfish template, but the gemspec specifies 's.rdoc_options = ["--main", "README.txt", "-SHN", "-f", "darkfish"]'. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-06-21 16:18 Message: I'm closing this ticket as we've moved to github issues for all issue tracking. Please refile this ticket there if you think it is still valid. https://github.com/rubygems/rubygems/issues Thanks, The RubyGems Team ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-06-07 16:50 Message: Hi! Believe it or not, we're moving to github's issue tracker! The pressure to move has been loud and clear, but for the longest time it didn't support the way we worked. Now that it has freeform labels it can support our workflow adequately. There is just one problem: Your bug is here and we don't want to lose you! What we'd like you to do is fairly painless and should only take a few minutes: Please file the _exact_ same ticket on github and provide a link back to this crufty old ticket so we can refer to any previous discussion that occurred. Once the new ticket is made, put a forwarding link to it here and close this ticket out. In a couple weeks, we'll track down the old tickets that are still open and decide what to do with them. We could have done this fairly automatically, but we really want you to do it so you're attached to the ticket and we can still communicate with you and keep a record of it. https://github.com/rubygems/rubygems/issues Thanks, The RubyGems Team ---------------------------------------------------------------------- Comment By: Eric Hodel (drbrain) Date: 2011-03-01 14:52 Message: I could not reproduce the behavior of --quiet suppressing the exit code with ci_reporter and RDoc 1.0.1, 2.3.0, 2.5.11 or trunk rdoc. I reverted the commit in RubyGems that add --quiet as it has no effect on the exit code. Reopened this bug. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-02-23 16:49 Message: DocManager was passing in --quiet which does a lot more than just "don't output stuff". I've removed that and forced the exit to be 1 if it borks. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28935&group_id=126 From noreply at rubyforge.org Tue Jun 21 19:18:10 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 21 Jun 2011 19:18:10 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-28945 ] When I request to install 8 gems, it installs 12 Message-ID: <20110621231810.E0583167835D@rubyforge.org> Bugs item #28945, was opened at 2011-02-22 14:56 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28945&group_id=126 Category: `gem install` command Group: None >Status: Closed >Resolution: Out of Date Priority: 1 Submitted By: Aaron Patterson (aaronp) Assigned to: Ryan Davis (zenspider) Summary: When I request to install 8 gems, it installs 12 Initial Comment: here is a video: http://www.youtube.com/watch?v=sgWr7lax9G8 Here is the output from my console: [aaron at YPCMC09458 dist (3-0-5-rc)]$ ls actionmailer-3.0.5.rc1.gem activeresource-3.0.5.rc1.gem actionpack-3.0.5.rc1.gem activesupport-3.0.5.rc1.gem activemodel-3.0.5.rc1.gem rails-3.0.5.rc1.gem activerecord-3.0.5.rc1.gem railties-3.0.5.rc1.gem [aaron at YPCMC09458 dist (3-0-5-rc)]$ ls | wc -l 8 [aaron at YPCMC09458 dist (3-0-5-rc)]$ gem list | grep 3.0.5 [aaron at YPCMC09458 dist (3-0-5-rc)]$ sudo gem install * Successfully installed activesupport-3.0.5.rc1 Successfully installed activemodel-3.0.5.rc1 Successfully installed actionpack-3.0.5.rc1 Successfully installed actionmailer-3.0.5.rc1 Successfully installed actionpack-3.0.5.rc1 Successfully installed activemodel-3.0.5.rc1 Successfully installed activerecord-3.0.5.rc1 Successfully installed activeresource-3.0.5.rc1 Successfully installed activesupport-3.0.5.rc1 Successfully installed railties-3.0.5.rc1 Successfully installed rails-3.0.5.rc1 Successfully installed railties-3.0.5.rc1 12 gems installed Installing ri documentation for activesupport-3.0.5.rc1... Installing ri documentation for activemodel-3.0.5.rc1... Installing ri documentation for actionpack-3.0.5.rc1... Installing ri documentation for actionmailer-3.0.5.rc1... Installing ri documentation for actionpack-3.0.5.rc1... Installing ri documentation for activemodel-3.0.5.rc1... Installing ri documentation for activerecord-3.0.5.rc1... Installing ri documentation for activeresource-3.0.5.rc1... Installing ri documentation for activesupport-3.0.5.rc1... Installing ri documentation for railties-3.0.5.rc1... Installing ri documentation for rails-3.0.5.rc1... file 'lib' not found Installing ri documentation for railties-3.0.5.rc1... Installing RDoc documentation for activesupport-3.0.5.rc1... ^[Installing RDoc documentation for activemodel-3.0.5.rc1... Installing RDoc documentation for actionpack-3.0.5.rc1... Installing RDoc documentation for actionmailer-3.0.5.rc1... Installing RDoc documentation for actionpack-3.0.5.rc1... Installing RDoc documentation for activemodel-3.0.5.rc1... Installing RDoc documentation for activerecord-3.0.5.rc1... Installing RDoc documentation for activeresource-3.0.5.rc1... Installing RDoc documentation for activesupport-3.0.5.rc1... Installing RDoc documentation for railties-3.0.5.rc1... Installing RDoc documentation for rails-3.0.5.rc1... file 'lib' not found Installing RDoc documentation for railties-3.0.5.rc1... [aaron at YPCMC09458 dist (3-0-5-rc)]$ ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-06-21 16:18 Message: I'm closing this ticket as we've moved to github issues for all issue tracking. Please refile this ticket there if you think it is still valid. https://github.com/rubygems/rubygems/issues Thanks, The RubyGems Team ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-06-07 16:50 Message: Hi! Believe it or not, we're moving to github's issue tracker! The pressure to move has been loud and clear, but for the longest time it didn't support the way we worked. Now that it has freeform labels it can support our workflow adequately. There is just one problem: Your bug is here and we don't want to lose you! What we'd like you to do is fairly painless and should only take a few minutes: Please file the _exact_ same ticket on github and provide a link back to this crufty old ticket so we can refer to any previous discussion that occurred. Once the new ticket is made, put a forwarding link to it here and close this ticket out. In a couple weeks, we'll track down the old tickets that are still open and decide what to do with them. We could have done this fairly automatically, but we really want you to do it so you're attached to the ticket and we can still communicate with you and keep a record of it. https://github.com/rubygems/rubygems/issues Thanks, The RubyGems Team ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28945&group_id=126 From noreply at rubyforge.org Tue Jun 21 19:18:10 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 21 Jun 2011 19:18:10 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29075 ] need for a post_install hook Message-ID: <20110621231811.018B11598077@rubyforge.org> Bugs item #29075, was opened at 2011-03-11 05:36 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29075&group_id=126 Category: `gem install` command (extensions) Group: next >Status: Closed >Resolution: Out of Date Priority: 3 Submitted By: Torsten Curdt (tcurdt) Assigned to: Ryan Davis (zenspider) Summary: need for a post_install hook Initial Comment: While there is Gem.post_install this cannot be used for gems that want to run some code on installation. In my particular case I need to compile some C++ code -a command line tool- that the gem depends on. It does not come with an extension though. Since there is no post_install hook exposed to the gem lifecycle people use the extconf for things like this. Since that one makes the assumption of building an extension, leaving out the create_makefile() results in Building native extensions. This could take a while... ERROR: Error installing ... ERROR: Failed to build gem native extension. No builder for extension 'path/to/extconf.rb' Which result in people doing things like this http://blog.costan.us/2008/11/post-install-post-update-scripts-for.html The best solution would certainly be to have some gem lifecyle hooks. But just making less assumption on the extension building would already be a first step. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-06-21 16:18 Message: I'm closing this ticket as we've moved to github issues for all issue tracking. Please refile this ticket there if you think it is still valid. https://github.com/rubygems/rubygems/issues Thanks, The RubyGems Team ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-06-07 16:50 Message: Hi! Believe it or not, we're moving to github's issue tracker! The pressure to move has been loud and clear, but for the longest time it didn't support the way we worked. Now that it has freeform labels it can support our workflow adequately. There is just one problem: Your bug is here and we don't want to lose you! What we'd like you to do is fairly painless and should only take a few minutes: Please file the _exact_ same ticket on github and provide a link back to this crufty old ticket so we can refer to any previous discussion that occurred. Once the new ticket is made, put a forwarding link to it here and close this ticket out. In a couple weeks, we'll track down the old tickets that are still open and decide what to do with them. We could have done this fairly automatically, but we really want you to do it so you're attached to the ticket and we can still communicate with you and keep a record of it. https://github.com/rubygems/rubygems/issues Thanks, The RubyGems Team ---------------------------------------------------------------------- Comment By: Torsten Curdt (tcurdt) Date: 2011-04-11 01:04 Message: Thanks, Ryan. If that's the case I think we can close this issue ...as soon as this is part of the documentation at least. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-04-08 12:30 Message: Torsten, yeah. You just set your gemspec's extensions field to point to the Rakefile: s.extensions = ["notext/#{self.name}/Rakefile"] and the rakefile should work like below or however you want it to work... it's just rake so you can do anything you want. ---------------------------------------------------------------------- Comment By: Torsten Curdt (tcurdt) Date: 2011-03-15 00:02 Message: Ryan, can elaborate or point me to an example how to do a "rake-based extension"? IIUC this means providing a Rakefile (or Makefile?) instead of the generated by the extconf? Still have your test project around? ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-03-14 14:01 Message: Just to make sure I understand: you have a pure ruby gem that calls out to a binary that you want to provide (build and install) via the gem. If that is accurate, I don't think that extra post_install hooks are the right way to go here. I think you can make this work via "normal" mechanisms. I think what you want to do is design a rake-based extension but then have that rakefile build and install your binary instead of a shared library. I just simulated this with a simple hoe-based project that had 'notext/blah/Rakefile' as it's extension and that rakefile just had: task :default => :build task :build do puts "building my cmdline tool!" touch "happy" end Upon packaging and installing, 'happy' was created inside the notext dir of the install. ---------------------------------------------------------------------- Comment By: Torsten Curdt (tcurdt) Date: 2011-03-14 11:55 Message: You can turn it like you want but building binaries is what rubygems is already doing today. They just get a different linker treatment. Not sure why one make such hard distinction there. Abuse scenarios are a bogus argument as long as the extconf (or for that matter - any code from the gem) gets executed. ---------------------------------------------------------------------- Comment By: Marcus Rueckert (darix) Date: 2011-03-14 11:02 Message: and any packaging system that uses post install hooks for building files *is* broken. i didnt even refer to potential abuse scenarios yet, building native extensions for ruby is certainly in the scope of rubygems. building binaries that get installed somewhere definitely is not. ---------------------------------------------------------------------- Comment By: Torsten Curdt (tcurdt) Date: 2011-03-14 10:04 Message: If that binary was something that would make sense outside of the gem I would agree - but it doesn't. Following your arguments all native code should live somewhere else - including the normal extensions. That would add a complexity to the system I don't see worth having. A post_install hook certainly gives room for abuse but it's a common pattern found in the various packaging systems. Not sure I would call this a broken feature. In fact I think the current build in assumptions are even worse. ---------------------------------------------------------------------- Comment By: Marcus Rueckert (darix) Date: 2011-03-14 08:47 Message: imho this is just the wrong approach, intree packaging like that just sucks. for users as for packagers. maybe the user has your binary installed already just outside of $PATH? while you could walk over $PATH and check if a binary with the desired name exists, you couldnt be sure that behind the filename is really the app you are expecting and that the version is compatible. handle the absence of the binary properly in your code and document for the user that a certain binary is required for proper functioning of your gem. I would really object adding a broken feature like this. ---------------------------------------------------------------------- Comment By: Torsten Curdt (tcurdt) Date: 2011-03-14 08:07 Message: You are probably right. As long as it is tracked as feature or bug I am fine. Thanks - the short term thing works. It's just ugly :) ---------------------------------------------------------------------- Comment By: Jon Forums (jonforums) Date: 2011-03-14 08:04 Message: Fair. IMO this issue should reappear as a feature request rather than stay a bug. And that would likely lead to relooking at plugin/hook visibility. I don't know what Eric wants for next steps on this, but since he asked you to open the issue, maybe it's enough to leave it as a bug. Good luck with whatever short-term solution you choose. ---------------------------------------------------------------------- Comment By: Torsten Curdt (tcurdt) Date: 2011-03-14 07:22 Message: Sorry, but the --init is more a work around than really an option. IMO a post_install hook for a gem is quite a natural thing to expect. If that's not on the table extconf should at least not make all those assumptions people hack around today. If you just close this issue people will continue to abuse the extconf like I am doing, too now. IMO an empty extconf should just not result in an error and we would be OKish. ---------------------------------------------------------------------- Comment By: Jon Forums (jonforums) Date: 2011-03-14 06:51 Message: While you could go down the plugin/hook path and split things something like... https://github.com/jonforums/prething https://github.com/jonforums/thing I think it's a bad fit for what you're trying to do...could become a tarbaby trying to keep the `prething` plugin from affecting other gems and coordinating with your main gem. Try building/installing the `prething` and see how globally it affects RG ops. Probably faster and more robust to add an `--init` to your gem's `bin\somthing` executable and document your gem's two-step install process in a `Gem::Specification.post_install_message` and your project doc. Any reason to keep this listed as an open RG bug? ---------------------------------------------------------------------- Comment By: Jon Forums (jonforums) Date: 2011-03-12 07:18 Message: That snippet from our install script results in a rubygems/defaults/operating_system.rb file being generated similar to the following: # :DK-BEG: override 'gem install' to enable RubyInstaller DevKit usage Gem.pre_install do |gem_installer| unless gem_installer.spec.extensions.empty? unless ENV['PATH'].include?('C:\DevKit\mingw\bin') then Gem.ui.say 'Temporarily enhancing PATH to include DevKit...' if Gem.configuration.verbose ENV['PATH'] = 'C:\DevKit\bin;C:\DevKit\mingw\bin;' + ENV['PATH'] end ENV['RI_DEVKIT'] = 'C:\DevKit' ENV['CC'] = 'gcc' ENV['CPP'] = 'cpp' ENV['CXX'] = 'g++' end end # :DK-END While my usage is fairly simple and the only mildly clever parts are (a) checking whether a native extension is being installed, and (b) wrapping the code snippet in markers so I can manage non-clobbering/upgrades of existing operating_system.rb files, I'm still betting that you could use `system` to call out to your toolchain and build your C++ tool in a similar way. It's the combination of the filename/location in combination with the block to Gem.pre_install which sets the pre-install hook that RG calls at the appropriate time during an install. These two places in the source should help: https://github.com/rubygems/rubygems/blob/master/lib/rubygems.rb#L65-82 https://github.com/rubygems/rubygems/blob/master/lib/rubygems/installer.rb#L140 ---------------------------------------------------------------------- Comment By: Torsten Curdt (tcurdt) Date: 2011-03-12 02:55 Message: @Jon: Still don't quite understand when you are setting that hook. Why would that code be called on a 'gem install' ? ---------------------------------------------------------------------- Comment By: Jon Forums (jonforums) Date: 2011-03-11 08:05 Message: In the DevKit (MSYS/MinGW toolchain for Windows) subproject of the RubyInstaller we have a Ruby install script which dynamically builds a gem override script that uses the pre-install hook to setup the environment for building native gems on Windows using the DevKit: https://github.com/oneclick/rubyinstaller/blob/master/resources/devkit/dk.rb.erb#L46-65 Basically, it automagically brings the DevKit toolchain into the environment when doing something like `gem install bson_ext` Thinking out loud, but I wonder if you can do something similar but use `system` or `IO.popen` to optimistically compile your gem's C++ dependency before the install and abort if you get any errors. Might also want to check/cleanup in post-build. A wild-eyed idea, but it might work if you can split things into "pre-build dependencies" and "build extension" and abort if things go badly. ---------------------------------------------------------------------- Comment By: Torsten Curdt (tcurdt) Date: 2011-03-11 07:46 Message: Maybe I misunderstood but I think Eric said on IRC that the existing post_install is not for gems. Which is why he asked me to open this issue. Jon, can you give an example how that would work? Whether it is pre or post install is not important to me. It's just that one might want to build more than just extension on install. I got that working by abusing the extconf to execute my build and creating an empty Makefile. But that smells. ---------------------------------------------------------------------- Comment By: Jon Forums (jonforums) Date: 2011-03-11 07:13 Message: Can you split things up to use the pre-install and post-build hooks which as of 1.5.0 that can cancel gem installation...optimistically compile in the pre-install and abort if needed in either pre-install or post-build? http://blog.segment7.net/2011/01/31/rubygems-1-5 ---------------------------------------------------------------------- Comment By: Torsten Curdt (tcurdt) Date: 2011-03-11 05:54 Message: Then you also cannot allow native builds. Where is the difference? ---------------------------------------------------------------------- Comment By: Luis Lavena (luislavena) Date: 2011-03-11 05:44 Message: I would say no to this. Most of the users do not check what the gem do inside, so there is a huge potential of security risks on this. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29075&group_id=126 From noreply at rubyforge.org Tue Jun 21 19:18:11 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 21 Jun 2011 19:18:11 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29145 ] Dynamically generated GemSpec.files ends up empty Message-ID: <20110621231811.1CCC41598087@rubyforge.org> Bugs item #29145, was opened at 2011-04-23 04:36 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29145&group_id=126 Category: `gem install` command Group: None >Status: Closed >Resolution: Out of Date Priority: 3 Submitted By: Lars Christensen (larsch) Assigned to: James Tucker (raggi) Summary: Dynamically generated GemSpec.files ends up empty Initial Comment: Prawn's gemspec: spec.files = Dir.glob("{examples,lib,spec,data}/**/**/*") + ["Rakefile", "prawn.gemspec"] With pristine 1.9.2-p180 on Windows (all good): C:\>gem --version 1.5.2 C:\>gem install prawn ... specifications/prawn-0.11.1.gemspec: s.files = ["examples/example_helper.rb"," examples/bounding_box/stretched_nesting.rb", "examples/bounding_box/bounding_boxes.rb", "examples/bounding_box/indentation.rb", ... ] With upgrades rubygems (s.files misses files): C:\>gem update --system ... C:\>gem --version 1.7.2 C:\>gem install prawn ... specifications/prawn-0.11.1.gemspec: s.files = ["HACKING", "README", "LICENSE", "COPYING"] All .rb files are missing in .files. Currently ocra (http://ocra.rubyforge.org/) uses .files to find the files that are included in a gem, and hence fails miserably when they are not actually listen in the .gemspec file. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-06-21 16:18 Message: I'm closing this ticket as we've moved to github issues for all issue tracking. Please refile this ticket there if you think it is still valid. https://github.com/rubygems/rubygems/issues Thanks, The RubyGems Team ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-06-07 16:50 Message: Hi! Believe it or not, we're moving to github's issue tracker! The pressure to move has been loud and clear, but for the longest time it didn't support the way we worked. Now that it has freeform labels it can support our workflow adequately. There is just one problem: Your bug is here and we don't want to lose you! What we'd like you to do is fairly painless and should only take a few minutes: Please file the _exact_ same ticket on github and provide a link back to this crufty old ticket so we can refer to any previous discussion that occurred. Once the new ticket is made, put a forwarding link to it here and close this ticket out. In a couple weeks, we'll track down the old tickets that are still open and decide what to do with them. We could have done this fairly automatically, but we really want you to do it so you're attached to the ticket and we can still communicate with you and keep a record of it. https://github.com/rubygems/rubygems/issues Thanks, The RubyGems Team ---------------------------------------------------------------------- Comment By: Luis Lavena (luislavena) Date: 2011-05-23 17:47 Message: I've bring this topic to RubyGems devel list before: http://rubyforge.org/pipermail/rubygems-developers/2011-May/006539.html Like you I depend on that functionality. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29145&group_id=126 From noreply at rubyforge.org Tue Jun 21 19:18:11 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 21 Jun 2011 19:18:11 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29170 ] with multiple sources, if one is unavailable, nothing works at all Message-ID: <20110621231811.45E5D1598085@rubyforge.org> Bugs item #29170, was opened at 2011-05-05 20:40 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29170&group_id=126 Category: `gem install` command Group: None >Status: Closed >Resolution: Out of Date Priority: 3 Submitted By: Nick Klauer (klauern) Assigned to: Ryan Davis (zenspider) Summary: with multiple sources, if one is unavailable, nothing works at all Initial Comment: With the Amazon outage, one of the sources I had added outside of rubygems was down (http://rubygems.torquebox.org). For me, this wasn't a big issue, since it hosts only a few gems that I use and I don't need updated that often. However, when trying to install a gem or update gems, it would shut down entirely, not being able to find specs.4.8.gz for that one source. So in effect, `gem update` was borked because one source wasn't available, regardless of the status of all others. If possible, can this just display a warning or something saying that "can't search ${borked gem server source}, skipping this one" and still try to update, install, etc., from any and all other sources listed? ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-06-21 16:18 Message: I'm closing this ticket as we've moved to github issues for all issue tracking. Please refile this ticket there if you think it is still valid. https://github.com/rubygems/rubygems/issues Thanks, The RubyGems Team ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-06-07 16:50 Message: Hi! Believe it or not, we're moving to github's issue tracker! The pressure to move has been loud and clear, but for the longest time it didn't support the way we worked. Now that it has freeform labels it can support our workflow adequately. There is just one problem: Your bug is here and we don't want to lose you! What we'd like you to do is fairly painless and should only take a few minutes: Please file the _exact_ same ticket on github and provide a link back to this crufty old ticket so we can refer to any previous discussion that occurred. Once the new ticket is made, put a forwarding link to it here and close this ticket out. In a couple weeks, we'll track down the old tickets that are still open and decide what to do with them. We could have done this fairly automatically, but we really want you to do it so you're attached to the ticket and we can still communicate with you and keep a record of it. https://github.com/rubygems/rubygems/issues Thanks, The RubyGems Team ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29170&group_id=126 From noreply at rubyforge.org Tue Jun 21 19:18:11 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 21 Jun 2011 19:18:11 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29173 ] cleanup should show me what other gems I have installed when determining whether to uninstall Message-ID: <20110621231811.766491678361@rubyforge.org> Bugs item #29173, was opened at 2011-05-06 06:24 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29173&group_id=126 Category: `gem` commands (other) Group: None >Status: Closed >Resolution: Out of Date Priority: 3 Submitted By: Nick Klauer (klauern) Assigned to: Ryan Davis (zenspider) Summary: cleanup should show me what other gems I have installed when determining whether to uninstall Initial Comment: When i do a `gem update` I often follow-up with `gem cleanup`. However, it's hard to tell whether to uninstall a gem when I see this: Attempting to uninstall warden-0.10.7 You have requested to uninstall the gem: warden-0.10.7 devise-1.1.2 depends on [warden (~> 0.10.7)] If you remove this gems, one or more dependencies will not be met. Continue with Uninstall? [Yn] I don't know if the newer version of warden is an entirely different version (1.0 or something) or compatible with the ~> requirement. Taken further, cleanup should know enough about the version requirement to save me the trouble of this anyway, especially if the requirement is =someversion, when you know that the gem authors don't want any other version. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-06-21 16:18 Message: I'm closing this ticket as we've moved to github issues for all issue tracking. Please refile this ticket there if you think it is still valid. https://github.com/rubygems/rubygems/issues Thanks, The RubyGems Team ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-06-07 16:50 Message: Hi! Believe it or not, we're moving to github's issue tracker! The pressure to move has been loud and clear, but for the longest time it didn't support the way we worked. Now that it has freeform labels it can support our workflow adequately. There is just one problem: Your bug is here and we don't want to lose you! What we'd like you to do is fairly painless and should only take a few minutes: Please file the _exact_ same ticket on github and provide a link back to this crufty old ticket so we can refer to any previous discussion that occurred. Once the new ticket is made, put a forwarding link to it here and close this ticket out. In a couple weeks, we'll track down the old tickets that are still open and decide what to do with them. We could have done this fairly automatically, but we really want you to do it so you're attached to the ticket and we can still communicate with you and keep a record of it. https://github.com/rubygems/rubygems/issues Thanks, The RubyGems Team ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-05-06 15:40 Message: I'm not sure whether my reverse-topo-sort ticket would address this or not. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29173&group_id=126 From noreply at rubyforge.org Tue Jun 21 19:18:11 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 21 Jun 2011 19:18:11 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29176 ] Scary warnings are scaring helpless developers who can't do a thing about it Message-ID: <20110621231811.B4C611598088@rubyforge.org> Bugs item #29176, was opened at 2011-05-06 13:07 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29176&group_id=126 Category: `gem` commands (other) Group: None >Status: Closed >Resolution: Out of Date Priority: 3 Submitted By: Alex Chaffee (alexch) Assigned to: Ryan Davis (zenspider) Summary: Scary warnings are scaring helpless developers who can't do a thing about it Initial Comment: Suddenly anyone using "gem" is seeing many repetitions of lines like this: NOTE: Gem::Specification#default_executable= is deprecated with no replacement. It will be removed on or after 2011-10-01. Gem::Specification#default_executable= called from /Users/chaffee/.rvm/gems/ruby-1.9.2-p0/specifications/thin-1.2.7.gemspec:10. Many of my students are completely freaking out since something that's supposed to just work -- e.g. "gem install rails" or "gem list"-- is now spewing a huge amount of scary noise about things which are currently working just fine, and which they have no ability to affect. Even developers with the acumen to be able to read, understand, and react to these messages are wasting time googling, often fruitlessly, since even if they find Ryan's blog post, and run "gem pristine --all --no-extensions", it doesn't make all the warnings disappear. Here's my suggested fix, in three independent parts. 1. Stop repeating the same message again and again; instead set a global flag (already_scared_user?) and STFU if it happens for a different gem 2. Put the advice about running "gem pristine --all --no-extensions" in the error message instead of forcing people to google to find a workaround 3. Before the warning, try to rewrite the offending gemfile yourself, as if the user had run "gem pristine". If the rewrite fails, only then scare the user. And please remember that the "gem" command is the user interface to the entire world of Ruby development, for people of all experience levels. You have a responsibility not to scare off our friends, new and old. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-06-21 16:18 Message: I'm closing this ticket as we've moved to github issues for all issue tracking. Please refile this ticket there if you think it is still valid. https://github.com/rubygems/rubygems/issues Thanks, The RubyGems Team ---------------------------------------------------------------------- Comment By: Alex Chaffee (alexch) Date: 2011-06-08 11:42 Message: Moved to https://github.com/rubygems/rubygems/issues/84 ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-06-07 16:50 Message: Hi! Believe it or not, we're moving to github's issue tracker! The pressure to move has been loud and clear, but for the longest time it didn't support the way we worked. Now that it has freeform labels it can support our workflow adequately. There is just one problem: Your bug is here and we don't want to lose you! What we'd like you to do is fairly painless and should only take a few minutes: Please file the _exact_ same ticket on github and provide a link back to this crufty old ticket so we can refer to any previous discussion that occurred. Once the new ticket is made, put a forwarding link to it here and close this ticket out. In a couple weeks, we'll track down the old tickets that are still open and decide what to do with them. We could have done this fairly automatically, but we really want you to do it so you're attached to the ticket and we can still communicate with you and keep a record of it. https://github.com/rubygems/rubygems/issues Thanks, The RubyGems Team ---------------------------------------------------------------------- Comment By: Chad Woolley (thewoolleyman) Date: 2011-06-02 08:50 Message: https://github.com/rubygems/rubygems/pull/66#issuecomment-1281426 ---------------------------------------------------------------------- Comment By: William Denniss (divzero) Date: 2011-05-25 04:23 Message: +1 that it would be good to reduce the 'scaryness'/volume of these warnings. I was setting up rails on a new machine for a colleague today. He saw all the errors and assumed the install was broken until I assured him it wasn't. I think it's good to have deprecation warnings ??but having so many, and for something that that needs to be fixed by the gem maintainers and not end-user-developers, doesn't seem to help. We were all 'helpless developers' once don't forget! Pull request #59 seems to fit the bill. ---------------------------------------------------------------------- Comment By: Chad Woolley (thewoolleyman) Date: 2011-05-24 17:05 Message: We are now getting duplicate pull requests in addition to Alex's (https://github.com/rubygems/rubygems/pull/66#issuecomment-1232323). May we please have the active maintainers weigh in on whether or not Alex's pull request can or cannot be merged? We can probably arrange to discuss on IRC if that is necessary... ---------------------------------------------------------------------- Comment By: Chad Woolley (thewoolleyman) Date: 2011-05-22 16:38 Message: Is there any reason not to merge Alex's patch? https://github.com/rubygems/rubygems/pull/59 He stepped up and wrote some code to make the situation better, and had it code-reviewed by Evan. Can we at least merge that or give feedback? ---------------------------------------------------------------------- Comment By: Jordan Sissel (jordansissel) Date: 2011-05-22 14:06 Message: I suspect this ticket not going to be resolved and is falling on deaf ears the ratio of "suck it up" responses to the "this sucks, please help" comments. If this is thie case, please just close this ticket with a resolution of whatever rubyforge's equivalent of "won't fix" with relevant links to workarounds. ---------------------------------------------------------------------- Comment By: Beoran Aegul (beoran) Date: 2011-05-22 01:10 Message: +1 for solution 1. Running gem pristine broke my rubygems, so I think it's a non-solution. I understand the need to clean up rubygems, but trying to force the whole ruby world to upgrade their gems specs so suddenly is not a good idea, IMHO. Not to mention many useful gems out there that are not maintained actively anymore. Kind Regards, B. ---------------------------------------------------------------------- Comment By: Alex Chaffee (alexch) Date: 2011-05-18 13:45 Message: Ping. My patch https://github.com/rubygems/rubygems/pull/59 doesn't change the inner workings at all, just improves the way deprecations are reported. Given that the idea is to get people to pay attention to them, it seems like people are more likely to pay attention to an organized list than a disorganized flood (especially since the list removes duplicates). Evan has code reviewed the patch and I implemented all his suggestions. ---------------------------------------------------------------------- Comment By: Luis Lavena (luislavena) Date: 2011-05-12 14:58 Message: Ryan, I think I did these steps before 1.8.2, I haven't tried it yet. Also since all my gems are fixed now, can't test again :-) ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-05-12 14:19 Message: Luis, unless I'm not understanding the rvm gem setup correctly, there is no need to do the `rvm use` line anymore. pristine had a bug with multiple repos that was fixed in 1.8.2. ---------------------------------------------------------------------- Comment By: Scott Tadman (tadman) Date: 2011-05-12 09:44 Message: Thanks, Luis, for that tip. I guess that means to upgrade rubygems the user is obligated to: rvmsudo bash gem pristine --all rvm use 1.9.2-p180 at global gem pristine --all Where this is documented other than this ticket, I have no idea. If I hadn't spent hours trying to remedy this, I would've just reverted to gem 1.6.0 and called it a day. If the intent of these warnings is to get people to upgrade, I have a feeling the opposite thing will occur. ---------------------------------------------------------------------- Comment By: Luis Lavena (luislavena) Date: 2011-05-12 08:22 Message: @Scott Tadman: gem pristine with "--no-extensions" will not fix gems that have extensions, that includes rcov, json, perftools. For that, you need "gem pristine" alone. As for rake, it is placed in the global namespace of RVM, so you need to switch to that namespace and correct it: rvm use 1.9.2-p180 at global gem pristine rake Then switch to your normal gemset. ---------------------------------------------------------------------- Comment By: Scott Tadman (tadman) Date: 2011-05-12 08:11 Message: Further investigation reveals that Jeweler's generated .gemspec file is affected by the version of rubygems installed, and that if building against a newer rubygems it will not put in the default_executable= call, so at least that much is fixed. However, the catch-22 here is that you need to build using a newer version of rubygems, which because of all the crazy warnings you get, I'm sure a lot of developers would avoid, instead reverting to an earlier, safer version. I have run gem pristine --all --no-extensions over six times on an OS X rvm-based Ruby 1.9.2 set of system gems and I'm still getting warnings. The first pass removed most, the second some, and the rest virtually none. I'm not sure why this needs to be run more than once in the first place, nor why this is the responsibility of the user. Now anything that even touches rubygems ends up getting lit up with warnings, the final few of which appear to be the most stubborn: NOTE: Gem::Specification#default_executable= is deprecated with no replacement. It will be removed on or after 2011-10-01. Gem::Specification#default_executable= called from /opt/local/rvm/gems/ruby-1.9.2-p180 at global/specifications/rake-0.8.7.gemspec:10. NOTE: Gem::Specification#default_executable= is deprecated with no replacement. It will be removed on or after 2011-10-01. Gem::Specification#default_executable= called from /opt/local/rvm/gems/ruby-1.9.2-p180/specifications/json-1.5.1.gemspec:10. NOTE: Gem::Specification#default_executable= is deprecated with no replacement. It will be removed on or after 2011-10-01. Gem::Specification#default_executable= called from /opt/local/rvm/gems/ruby-1.9.2-p180/specifications/perftools.rb-0.5.6.gemspec:10. NOTE: Gem::Specification#default_executable= is deprecated with no replacement. It will be removed on or after 2011-10-01. Gem::Specification#default_executable= called from /opt/local/rvm/gems/ruby-1.9.2-p180/specifications/rcov-0.9.9.gemspec:11. (in /Users/tadman/git/pigeon) It is worrying that the pristine operation not only produces ~500KB of warnings when processing its various things which buries any actual errors in the process. Maybe there's a reason why these gems can't be pristined properly, but it gets lost in the hurricane of warnings. ---------------------------------------------------------------------- Comment By: Mike Bethany (mikbe) Date: 2011-05-12 00:36 Message: The deprecation warnings made it virtually impossible to work. Every time autotest ran I would have a screen full of gobbledygook I had to sort through, very annoying. I wrote Chicken Little to disable the deprecation warnings just for the two major offenders. You can install the gem with: `gem install chicken_little` then run it `chicken_little install` You can also just go in and edit the RubyGems specification.rb file yourself and comment out those lines. Source: https://github.com/mikbe/chicken_little RubyGems: https://rubygems.org/gems/chicken_little P.S. RubyGems 1.8.2 seems to be broken in Ubuntu 10.10. Funny enough in the specification.rb file at line 277. Though it seems to be OK in OS X 10.6.7. ---------------------------------------------------------------------- Comment By: Alex Chaffee (alexch) Date: 2011-05-11 16:25 Message: I've gone ahead and made a patch. My fork of rubygems still prints out warnings, but after the first warning, it buffers up all remaining warnings and then emits them at_exit in a somewhat nicer report format, like this: Some of your installed gems called deprecated methods. See http://blog.zenspider.com/2011/05/rubygems-18-is-coming.html for background. Use 'gem pristine --all' to fix or 'rubygems update --system 1.7.2' to downgrade. TestDeprecate::Thing#foo is deprecated; use bar instead. It will be removed on or after 2099-03-01. called from /Users/chaffee/dev/rubygems/test/rubygems/test_deprecate.rb:174 called from /Users/chaffee/dev/rubygems/test/rubygems/test_deprecate.rb:175 called from /Users/chaffee/dev/rubygems/test/rubygems/test_deprecate.rb:177 TestDeprecate::Thing#goo is deprecated; use bar instead. It will be removed on or after 2099-04-01. called from /Users/chaffee/dev/rubygems/test/rubygems/test_deprecate.rb:176 I also pulled in the "--no-warnings" patch, but set the default back to "show all warnings" (i.e. skip=false). https://github.com/alexch/rubygems/commit/5572c2c1bb88e2e1b55b8d62 3fe4ef58a954c2a1 ---------------------------------------------------------------------- Comment By: Scott Tadman (tadman) Date: 2011-05-11 11:06 Message: Part of this problem is that Jeweler, a gem used by many authors to build their gems, inserts the default_executable= line in all the .gemspec files it produces. This is something done without the knowledge of the authors, and as one, I'm not even sure how to turn it off. I'll have to do more research. In the mean-time I need to live with the guilt and shame of causing warnings for everyone using anything I've made. I do want to keep up to date. I use Ruby 1.9.2 and the latest everything for new projects, but there are many legacy applications I'm involved with that for reasons of budget, dependency hell, or otherwise, are constrained to specific older versions. What I'm asking is why methods can't be deprecated by rendering them non-functional instead of causing things to explode by calling methods that no longer exist. It is common practice amongst UNIX shell utilities to have non-functional arguments for this very reason. I'm not saying to support the API, but at least make it mostly compatible with the newest spec even if it may not perform exactly as intended. For instance, most browsers don't support the tag, but they also don't refuse to render the page because of a lack of support. Once again, these are not my "decrepit needs", but rather the fact that there are hundreds if not thousands of gems out there with this mostly useless call to default_executable= as inserted by Jeweler and others that could be harmlessly ignored. I will post another ticket relating to the warnings later if I can replicate it. I have mostly fixed the issue using the pristine option which should be advertised more clearly or, better yet, done automatically when gem is updated to the newest release. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-05-11 02:02 Message: Scott, Please file a ticket with details and, if possible, reproduction steps showing that rolling back to 1.7.2 still has deprecation warnings that were added to 1.8.0. If it isn't too much to ask, please file a ticket with details and, if possible, reproduction steps showing "literally, 4000+ lines of warnings when running ordinary rake tasks" after running `gem pristine --all --no-extensions`. Do note that I suspect there is a bug in `gem pristine` in scenarios like using rvm w/ multiple gem directories... I don't have a repro for that yet. Finally, the majority of these deprecations are created _by_ rubygems in gemspecs and are fixable _by_ rubygems (pristine bugs notwithstanding)... Those warnings that are left afterwards represent real usage of methods that ARE going away. You state that you're intentionally running old gems on your apps but you insist on updating rubygems & bundler... You're going to update to a version that doesn't have the implementation one of your decrepit needs. What is your plan for that? Do you really think it reasonable that we should keep around API supporting everything all the way back to 2004? I'm sorry, but that just doesn't seem sane to me. We have to move on, even if you won't. ---------------------------------------------------------------------- Comment By: Scott Tadman (tadman) Date: 2011-05-10 21:37 Message: This issue is driving me berserk. I've pristined, I've rolled back to 1.7.2 like the Germans retreating from Russia and still I'm getting nagged and hassled. When something like default_executable is specified in default gemspec files that Jeweler produces and other templates that many have used to build out their gemspecs, it does seem like a bit of a nuisance. Maybe it's better to rescind support for it and turn it into a method that does nothing simply for compatibility reasons. Document the method as deprecated and non-functional for the curious. Lobby to get it removed from examples and places like Jeweler. I have applications with dozens of deliberately old versions of gems because the associated applications aren't up to date and upgrading causes problems. The one thing I do want to keep up to date is support utilities like gem and bundler, though, and getting, literally, 4000+ lines of warnings when running ordinary rake tasks is not helping. Even if I nagged and hassled every single gem builder, and seriously, I have nagged many about Ruby 1.9 issues, this still wouldn't matter because I simply have older versions of gems installed that cannot be patched without altering the space-time continuum. This is basically condemning me to using an antiquated version of gem so long as I have even one squeaky wheel in the whole system, as a single out of date gem will produce warnings for every gem related operation. When installing a new gem, if strictly necessary, it could say that the .gemspec is out of date and should be updated while hinting at the obscure pristine command as to how that might remedy it. I have wildly different versions of gem installed on my systems, but it's as if every time I go to update to the latest I get slapped in the face with something like this. I honestly wonder how other people have fared. After a lot of fussing about, experimenting with different approaches and attempting to be as unobtrusive as possible, I have come up with a patch that enables Deprecate.skip by default and also allows the setting to be toggled on or off as desired using the --warnings or --no-warnings options for install. After inspecting the implementation of this, which appears to have erupted into the root namespace as the module Deprecate, and without any sort of unit test, I have inverted the default because warnings are generated before command options are processed and there does not appear to be any other way. Patch: https://gist.github.com/965921 ---------------------------------------------------------------------- Comment By: Stephen Bannasch (stepheneb) Date: 2011-05-10 20:13 Message: For now I'm using this solution: gem update --system 1.7.2 Thanks Luis -- I didn't remember how easy it was to downgrade RubyGems. After running: gem pristine --all --no-extensions -- running a single spec test In my rails 2.3.11 project with RubyGems 1.8.1 generates 317 lines of warnings before I see the 10 lines of results: https://gist.github.com/965850 It's certainly annoying enough to get me to plan to fix my gem (jnlp) but my one gem is just a tiny bit of the noise in general. ---------------------------------------------------------------------- Comment By: Jordan Sissel (jordansissel) Date: 2011-05-10 18:36 Message: FWIW, I support deprecations, but these warning messages are going to users, not developers. And that sucks. For example, all my ruby nagios alerts are filled, now, with pointless warnings about libraries my code is *not* using. So many warnings, in fact, that the test code's output is lost. This warning should pop up when developers run 'gem build foo.gemspec' and no other time. Why? Consider a user who has code that relies on rake '0.8.0' explicitly. You can't actually fix 'rake 0.8.0' on rubygems.org because you can't overwrite an existing release (for good reason). So now, for eternity, this user is stuck with warning messages. ---------------------------------------------------------------------- Comment By: Alex Chaffee (alexch) Date: 2011-05-10 10:55 Message: Chad - A two-line warning per gem would still be super noisy. One compromise would be to queue up a list of offending gems per warning and then emit them all on_exit in a single line. As for patches, as I said before, I'd be happy to spend my time working on that, but not until I get the goahead from a member of the core team (especially considering that first comment). ---------------------------------------------------------------------- Comment By: Scott Tadman (tadman) Date: 2011-05-10 09:26 Message: I just "upgraded" gem and now I'm greeted with over a thousand lines of warnings, nearly one for every gem I have installed on my system. It doesn't just warn for gems I use, but any gems I might happen to have that are out of date. The message itself is meaningless as there's really nothing I can do about it, and further, it doesn't seem like ignoring that directive instead of complaining about it would have much of an effect on the end user. Since when is it the responsibility of gem users to hassle gem builders into compliance? Why can't the gem build operation give the builder a hard time instead? Why can't rubygems.org reject the gem out of protest? As a note, I'm also getting a kabillion identical warnings apparently from rubygems itself: Gem::SourceIndex#add_spec called from /opt/local/rvm/rubies/ree-1.8.7-2011.03/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:127. NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It will be removed on or after 2011-11-01. Gem::SourceIndex#add_spec called from /opt/local/rvm/rubies/ree-1.8.7-2011.03/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:127. NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It will be removed on or after 2011-11-01. Gem::SourceIndex#add_spec called from /opt/local/rvm/rubies/ree-1.8.7-2011.03/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:127. NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It will be removed on or after 2011-11-01. Gem::SourceIndex#add_spec called from /opt/local/rvm/rubies/ree-1.8.7-2011.03/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:127. NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It will be removed on or after 2011-11-01. Gem::SourceIndex#add_spec called from /opt/local/rvm/rubies/ree-1.8.7-2011.03/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:127. NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It will be removed on or after 2011-11-01. Gem::SourceIndex#add_spec called from /opt/local/rvm/rubies/ree-1.8.7-2011.03/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:127. NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It will be removed on or after 2011-11-01. Gem::SourceIndex#add_spec called from /opt/local/rvm/rubies/ree-1.8.7-2011.03/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:127. NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It will be removed on or after 2011-11-01. Gem::SourceIndex#add_spec called from /opt/local/rvm/rubies/ree-1.8.7-2011.03/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:127. NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It will be removed on or after 2011-11-01. ---------------------------------------------------------------------- Comment By: Chad Woolley (thewoolleyman) Date: 2011-05-08 11:43 Message: I agree, it would be nice if the deprecation warning were once per gem (NOT once for all gems as Alex suggested; that would defeat the purpose of getting people to complain to gem authors to fix their specs) However, I don't see any patches or even failing tests attached to this ticket yet... ---------------------------------------------------------------------- Comment By: Loren Segal (lsegal) Date: 2011-05-08 09:40 Message: Ryan, I'm not too sure if you read the entirety of my message. Just in case, I'll summarize again: 1. I agree that having warnings telling developers to update their APIs is good. I believe I said that. (Feel free to check) 2. The issue in this report is not about whether the warnings should exist or not, because everybody here agrees they should. The issue is how often they need to be printed. Given that I am suggesting the same fix as Alex, I don't see how this falls out of the scope of the ticket. 3. My feedback was not (entirely) a "me too". I am simply trying to provide extra information regarding the breadth of this issue that others might not be aware of; specifically that `gem pristine --all` is not a complete solution to this issue, at least it does not guarantee the hiding of all warning *spam* (remember, not arguing about first-time warnings, but complete page-spam). As far as I know, that problem was not yet discussed. I'm of the opinion that all relevant information should be provided with a bug report. There's no need to jump down users throats for providing extra information, so please try to use your indoor voice. 3. I don't see why modifying the warnings to show once (per method) needs to be controversial. It seems like quite a simple and reasonable change, at least to me. Is it not reasonable to you? Why not? Finally, as far as I know, open source relies on feedback from the community; certainly a tool that is widely used and part of Ruby's standard library deserves feedback from all of the community. Telling users that they are not allowed to voice their opinion on an open ticket simply does not compute. I'm therefore politely declining your invitation to "get off this ticket". Though, I suppose this should have prefaced the response with this note instead. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-05-08 01:56 Message: No worries. ---------------------------------------------------------------------- Comment By: Justin Collins (presidentbeef) Date: 2011-05-07 23:57 Message: Sorry, my mistake. I didn't notice that gem was called out specifically. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-05-07 23:54 Message: Justin, As described at http://blog.zenspider.com/2011/05/rubygems-18-is-coming.html and elsewhere, rake is one of those unfortunate gems that explicitly uses the deprecated API in their gemspec. Please file a bug on the rake bug tracker. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-05-07 23:53 Message: Loren, Get off this ticket. Everything you just described falls outside of the scope of this ticket. Specifically: "helpless developers". The point of having deprecations at all is to get those "hundreds" of libraries that use deprecated API to update their code. If you want to "me too", then yippie... but your hyperbole isn't a "me too" it is a completely separate issue (and one I will more readily reject). ---------------------------------------------------------------------- Comment By: Justin Collins (presidentbeef) Date: 2011-05-07 23:19 Message: I did a fresh install of 1.9.2 with rvm, then upgraded Ruby Gems. The only gem installed was "rake", and after running "gem pristine --all", "gem pristine --all --no-extensions", and "gem pristine rake", I still get the following error: NOTE: Gem::Specification#default_executable= is deprecated with no replacement. It will be removed on or after 2011-10-01. Gem::Specification#default_executable= called from /home/justin/.rvm/gems/ruby-1.9.2-p180 at global/specifications/rake-0.8.7.gemspec:10. ---------------------------------------------------------------------- Comment By: Loren Segal (lsegal) Date: 2011-05-07 22:40 Message: I have to agree with the severity of this issue. The problem is unfortunately not just limited to the `gem` binary. Any library making use of deprecated APIs will also get these warnings ad-infintum, so gem pristinie --all doesn't solve this issue, only small one part of it. For example, any gem that makes use of SourceIndex will see these deprecation warnings on each usage. There are currently hundreds of libraries that make use of this class, as per my latest search on codesearch: http://codesearch.google.com/codesearch?q=SourceIndex+lang:ruby and http://codesearch.google.com/codesearch?q=Gem.source_index+lang%3Aruby You might get lucky and just see a few of these warnings, but if the method is called within a loop, RubyGems will not be forgiving, and spam you many, many, times (see http://codesearch.google.com/codesearch/p?hl=en#L18QHnAzSFA/bin/minigem&q=Gem.source_index%20lang:ruby&sa=N&cd=46&ct=rc for just one random example). In some cases, this output may even render the lib/tool completely unusable, especially if it relies heavily on console output. Because of that possibility, an otherwise innocuous (and transitional) warning can become a "severe" compatibility bug. Just like Alex, I'm all for warnings, but I foresee a lot of developers scrambling to provide fixes for their users in the coming months, especially in the cases where their tools start scrolling pages of warnings just because of one method call. I'm not sure devs or users will be too happy about this. Fortunately the fix is simple, as Alex pointed pointed out. I think it would be sensible to add the suggested "already_scared_user?" flag; it can probably be done on a per method name granularity. Given that all of the deprecations are wrapped inside a Deprecation module AFAIK(?), this should be pretty simple to add. ---------------------------------------------------------------------- Comment By: Luis Lavena (luislavena) Date: 2011-05-06 15:04 Message: Which gem was not solved by gem pristine --all? please provide complete output, we can't help without the output. As for drowning on this issue: revert back to 1.7.2 There is no easy way to solve existing gem specifications without doing gem pristine --all And we can't help solve the others without people telling us which ones didn't get fixed for us to look at *why*. So, I know were are you coming from, heck, I work on Windows, what more weird scenario for failures could be than that? And even so, gem pristine --all solved all the issues. Help us help you. ---------------------------------------------------------------------- Comment By: Alex Chaffee (alexch) Date: 2011-05-06 14:41 Message: Luis - thanks, "gem pristine -all" has fixed most -- but still not quite all -- of the messages. Warnings are indeed good, but only until they become noise. That is extra bad since it can drown out other important information, especially for less experienced people who are mystified by everything coming down on the console. One reason I'm concerned about this is that tonight in two different cities we're doing a Railsbridge Ruby For Women Workshop Install Fest, and most of the students won't understand what's going on, and the volunteers may not either. This will add chaos to an already chaotic and frustrating session. Not your problem, I know, but I wanted you to know where I'm coming from. ---------------------------------------------------------------------- Comment By: Luis Lavena (luislavena) Date: 2011-05-06 13:38 Message: gem pristine --all --no-extensions will fix the gems that do not have extensions You need to do gem pristine -all, but that will not accept parameters for each gem. In my case I didn't require additional parameters to each gem so a simple gem pristine --all solved all the warnings. Warnings are good, and as always, you can rollback to previous versions if you find it doesn't work for you: gem update --system 1.7.2 ---------------------------------------------------------------------- Comment By: Alex Chaffee (alexch) Date: 2011-05-06 13:27 Message: I wasn't trying to be inflammatory. This is a real problem, wasting the real time of real people across the world. And I'd be happy to submit a patch but somehow it doesn't seem likely you'd accept it. ---------------------------------------------------------------------- Comment By: Erik Hollensbe (erikh) Date: 2011-05-06 13:22 Message: Really? Don't you have anything better to do than to post inflammatory shit to this tracker? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29176&group_id=126 From noreply at rubyforge.org Tue Jun 21 19:20:28 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 21 Jun 2011 19:20:28 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29249 ] Can't downgrade to 1.37 from 1.8.5 Message-ID: <20110621232028.C55F3185838A@rubyforge.org> Bugs item #29249, was opened at 2011-06-03 11:15 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29249&group_id=126 Category: `gem install` command Group: None >Status: Closed >Resolution: Rejected Priority: 3 Submitted By: Luis Lavena (luislavena) Assigned to: Evan Phoenix (evan) Summary: Can't downgrade to 1.37 from 1.8.5 Initial Comment: User following the instructions form UPGRADING was not able to downgrade properly under Ruby 1.9.2: http://help.rubygems.org/discussions/problems/617-downgrading-rubygems-from-185-to-137-gives-an-error Find here a gist of the error: https://gist.github.com/1006834 Either the issue need to be corrected or the documentation needs to reflect the limitation. Thank you. ---------------------------------------------------------------------- >Comment By: Ryan Davis (zenspider) Date: 2011-06-21 16:20 Message: The UPGRADING document says: === 1.9.2 Downgrade from Rubygems 1.4.x+ to stock 1.9 rubygems: Use sudo/su as appropriate: $ ruby --disable-gems -S gem which rubygems ~/.rvm/rubies/ruby-1.9.2-p136/lib/ruby/site_ruby/1.9.1/rubygems.rb $ rm ~/.rvm/rubies/ruby-1.9.2-p136/lib/ruby/site_ruby/1.9.1/rubygems.rb $ rm -rf ~/.rvm/rubies/ruby-1.9.2-p136/lib/ruby/site_ruby/1.9.1/rubygems $ gem -v 1.3.7 ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-06-07 16:50 Message: Hi! Believe it or not, we're moving to github's issue tracker! The pressure to move has been loud and clear, but for the longest time it didn't support the way we worked. Now that it has freeform labels it can support our workflow adequately. There is just one problem: Your bug is here and we don't want to lose you! What we'd like you to do is fairly painless and should only take a few minutes: Please file the _exact_ same ticket on github and provide a link back to this crufty old ticket so we can refer to any previous discussion that occurred. Once the new ticket is made, put a forwarding link to it here and close this ticket out. In a couple weeks, we'll track down the old tickets that are still open and decide what to do with them. We could have done this fairly automatically, but we really want you to do it so you're attached to the ticket and we can still communicate with you and keep a record of it. https://github.com/rubygems/rubygems/issues Thanks, The RubyGems Team ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29249&group_id=126 From noreply at rubyforge.org Tue Jun 21 19:21:12 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 21 Jun 2011 19:21:12 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29257 ] Massively Duplicated Deprecation Warnings Message-ID: <20110621232112.D6007185838A@rubyforge.org> Bugs item #29257, was opened at 2011-06-06 13:27 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29257&group_id=126 Category: None Group: None >Status: Closed >Resolution: Out of Date Priority: 3 Submitted By: Scott Tadman (tadman) Assigned to: Nobody (None) Summary: Massively Duplicated Deprecation Warnings Initial Comment: I've added a pull request that tries to address some of the issues bundler has with deprecated functions: https://github.com/rubygems/rubygems/pull/70 This simply tracks which deprecations have been fired and doesn't trigger warnings for the same source line + method combination. The 1.8.5 version will report on deprecations an infinite number of times, something that nearly happens when some things are exercised inside a loop. Gem::SourceIndex#add_specs calls Gem::SourceIndex#add_spec many, many times, and both methods are deprecated. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-06-21 16:21 Message: I'm closing this ticket as we've moved to github issues for all issue tracking. Please refile this ticket there if you think it is still valid. https://github.com/rubygems/rubygems/issues Thanks, The RubyGems Team ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-06-07 16:50 Message: Hi! Believe it or not, we're moving to github's issue tracker! The pressure to move has been loud and clear, but for the longest time it didn't support the way we worked. Now that it has freeform labels it can support our workflow adequately. There is just one problem: Your bug is here and we don't want to lose you! What we'd like you to do is fairly painless and should only take a few minutes: Please file the _exact_ same ticket on github and provide a link back to this crufty old ticket so we can refer to any previous discussion that occurred. Once the new ticket is made, put a forwarding link to it here and close this ticket out. In a couple weeks, we'll track down the old tickets that are still open and decide what to do with them. We could have done this fairly automatically, but we really want you to do it so you're attached to the ticket and we can still communicate with you and keep a record of it. https://github.com/rubygems/rubygems/issues Thanks, The RubyGems Team ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29257&group_id=126 From ryand-ruby at zenspider.com Tue Jun 21 19:33:40 2011 From: ryand-ruby at zenspider.com (Ryan Davis) Date: Tue, 21 Jun 2011 16:33:40 -0700 Subject: [Rubygems-developers] moving to github issues In-Reply-To: <7268E5FA-B7B8-42AB-82B2-D9B6E1EEAB1F@zenspider.com> References: <7268E5FA-B7B8-42AB-82B2-D9B6E1EEAB1F@zenspider.com> Message-ID: <649B9072-4C57-41E7-A0BE-FB904A5A9E74@zenspider.com> On Jun 7, 2011, at 17:11 , Ryan Davis wrote: > I just activated github issues for rubygems and added a bunch of labels to help us replicate the workflow from rubyforge's issue tracker (eg resolution, category, and status). I've added a canned message to the 3 trackers we had and mass blatted all open tickets to get the owners to migrate their tickets to github issues. > > As such... there be noise. Two weeks ago I announced that we were migrating to github issues. I gave everyone some time to move their tickets over so they'd be able to continue tracking them. I just reviewed the remaining tickets, manually transferred a few over and closed out the rest. I'm going to wait a while so that people can catch up with their email in case they missed my announcement and on Friday I'm going to turn off the trackers on rubyforge (I believe this only removes the links to the feature so everything should still work). So... That should be the end of the noise. From noreply at rubyforge.org Wed Jun 22 12:59:17 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 22 Jun 2011 12:59:17 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29163 ] Invalid specs resulting from incorrect syck time parsing Message-ID: <20110622165917.6CDD01858376@rubyforge.org> Bugs item #29163, was opened at 2011-05-04 20:14 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29163&group_id=126 Category: `gem` commands (other) Group: next Status: Closed Resolution: Accepted Priority: 3 Submitted By: Bruno Michel (nono) Assigned to: Evan Phoenix (evan) Summary: Invalid specs resulting from incorrect syck time parsing Initial Comment: Hi, I have the bug described on https://github.com/rubygems/rubygems/pull/57 with Ruby 1.9.2-p180 and Rubygems v1.8.0. If I generate a gem with `gem build`, the `date` field in the metadata of the generated gem is: date: 2011-05-04 00:00:00.000000000Z If I push this gem on rubygems.org and try to install it remotely (same PC), this does not works: ERROR: While executing gem ... (NameError) uninitialized constant Psych::Syck ---------------------------------------------------------------------- Comment By: Dan Peterson (dpiddy) Date: 2011-06-22 13:59 Message: Should the fix be extended to `marshal_dump` as well? I'm running into a problem on our internal gems repo where built-gem metadata is being uploaded with unquoted ='s. When `gem generate_index` is run, the metadata is loaded which turns the = into DefaultKey. That's then marshaled out as part of the quick specs which breaks clients that try to load them. Applying the same fix to `marshal_dump` let quick specs be generated that didn't have DefaultKey refs in them even though the incoming gem specs were broken. ---------------------------------------------------------------------- Comment By: Bruno Michel (nono) Date: 2011-06-01 17:53 Message: Oki, now I understand from where this DefaultKey come. Thanks ---------------------------------------------------------------------- Comment By: Evan Phoenix (evan) Date: 2011-06-01 17:45 Message: Yep. You can see the syck bug by running this code: YAML.load "- - =\n - 1\n" You'll see that syck puts DefaultKey in there, which is just plain wrong. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-06-01 17:42 Message: The problem is that psych will generate a perfectly valid string that starts with an unquoted '='. Syck has a bug parsing that and winds up using DefaultKey. ---------------------------------------------------------------------- Comment By: Bruno Michel (nono) Date: 2011-06-01 16:13 Message: Thanks for the explanation. The gem was regenerated with a Ruby 1.8 and a new version was pushed. If I want to build the next version with Ruby 1.9, how can I can be sure the new gem don't have a YAML::Syck::DefaultKey? ---------------------------------------------------------------------- Comment By: Evan Phoenix (evan) Date: 2011-06-01 15:09 Message: I've fixed this by having the DefaultKey class always available and having Requirement fix up any reference to it. Fixed in github:0f4067a ---------------------------------------------------------------------- Comment By: Evan Phoenix (evan) Date: 2011-06-01 13:16 Message: This is because html_spellchecker has an instance of YAML::Syck::DefaultKey in its gemspec. These should not be in gemspecs and the gem needs to be regenerated. I'm looking into a way to mitigate this in the mean time. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-05-24 07:20 Message: I think it is your cache... That URL looks OK via: curl http://gems:Nasom4 at gems.af83.com/specs.4.8.gz | gunzip -dc | ruby -Ilib -rubygems -e 'p Marshal.load $stdin.read' ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-05-24 07:12 Message: Bruno, this installs fine for me as you can see below... From your output, I suspect you might have a bad source in your list. Specifically "gems.af83.com" looks like it might be bad for you. Can you do `gem sources -c` to ensure that your sources are default and your caches are cleared and try again to verify? % gem i -i xxx html_spellchecker --version=0.1.1 -V --backtrace GET http://rubygems.org/specs.4.8.gz 302 Found GET http://production.s3.rubygems.org/specs.4.8.gz 200 OK GET http://rubygems.org/quick/Marshal.4.8/html_spellchecker-0.1.1.gemspec.rz ... and so on to completion ... ---------------------------------------------------------------------- Comment By: Bruno Michel (nono) Date: 2011-05-24 06:43 Message: Hi, for example: ~% gem install html_spellchecker --version=0.1.1 -V --backtrace GET http://rubygems.org/specs.4.8.gz 302 Found GET http://production.s3.rubygems.org/specs.4.8.gz 304 Not Modified GET http://gems:Nasom4 at gems.af83.com/specs.4.8.gz 200 OK ERROR: While executing gem ... (NameError) uninitialized constant Psych::Syck /home/nono/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:640:in `load' /home/nono/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:640:in `_load' /home/nono/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/spec_fetcher.rb:134:in `load' /home/nono/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/spec_fetcher.rb:134:in `fetch_spec' /home/nono/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/spec_fetcher.rb:95:in `block in fetch_with_errors' /home/nono/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/spec_fetcher.rb:94:in `map' /home/nono/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/spec_fetcher.rb:94:in `fetch_with_errors' /home/nono/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/dependency_installer.rb:110:in `find_gems_with_sources' /home/nono/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/dependency_installer.rb:228:in `find_spec_by_name_and_version' /home/nono/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/dependency_installer.rb:259:in `install' /home/nono/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/commands/install_command.rb:121:in `block in execute' /home/nono/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/commands/install_command.rb:115:in `each' /home/nono/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/commands/install_command.rb:115:in `execute' /home/nono/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/command.rb:278:in `invoke' /home/nono/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/command_manager.rb:147:in `process_args' /home/nono/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/command_manager.rb:117:in `run' /home/nono/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/gem_runner.rb:65:in `run' /home/nono/.rvm/rubies/ruby-1.9.2-p180/bin/gem:21:in `
' zsh: exit 1 ~% gem -v 1.8.3 ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-05-23 21:38 Message: I need a full backtrace and the gem name+version to properly investigate. Your error doesn't jive with the date problem. (If I'm remembering the error correctly). ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29163&group_id=126 From ryand-ruby at zenspider.com Fri Jun 24 16:58:44 2011 From: ryand-ruby at zenspider.com (Ryan Davis) Date: Fri, 24 Jun 2011 13:58:44 -0700 Subject: [Rubygems-developers] moving to github issues In-Reply-To: <649B9072-4C57-41E7-A0BE-FB904A5A9E74@zenspider.com> References: <7268E5FA-B7B8-42AB-82B2-D9B6E1EEAB1F@zenspider.com> <649B9072-4C57-41E7-A0BE-FB904A5A9E74@zenspider.com> Message-ID: <20C3B2D7-77B2-4CAC-95C2-DEC96BC8DDD1@zenspider.com> On Jun 21, 2011, at 16:33 , Ryan Davis wrote: > Two weeks ago I announced that we were migrating to github issues. I gave everyone some time to move their tickets over so they'd be able to continue tracking them. I just reviewed the remaining tickets, manually transferred a few over and closed out the rest. I'm going to wait a while so that people can catch up with their email in case they missed my announcement and on Friday I'm going to turn off the trackers on rubyforge (I believe this only removes the links to the feature so everything should still work). > > So... That should be the end of the noise. trackers have been turned off... I also turned off news (I should do this on all my projects) and scm. From noreply at rubyforge.org Wed Jun 29 20:36:07 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 29 Jun 2011 20:36:07 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29300 ] gem and require behavior changed Message-ID: <20110630003607.33BC218581B2@rubyforge.org> Bugs item #29300, was opened at 2011-06-29 17:36 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29300&group_id=126 Category: #gem and #require methods Group: None Status: Open Resolution: None Priority: 3 Submitted By: Tom Trebisky (trebisky) Assigned to: Nobody (None) Summary: gem and require behavior changed Initial Comment: Once upon a time I had a script that worked, it used activerecord and pulled in that gem via the 3 lines: require "rubygems" gem "activerecord" require "activerecord" Now the script fails with /usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:53:in `gem_original_require': no such file to load -- activerecord (LoadError) from /usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:53:in `require' But I have a working rails install, so I know activerecord is on my system and healthy. After hours and hours of frustration, I find I can fix things by changing the above 3 lines to: require "rubygems" require "active_record" My take on this is that the behavior of the gem commands changed (I am now using rubygems 1.8.5, but 1.7.2 exhibited the same breakage). In the good old days, the gem command activated the activerecord gem and did some magic so the require would work (despite the unfortunately different naming of the file providing the gem). Maybe somebody decided that the magic was a bad idea? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29300&group_id=126 From noreply at rubyforge.org Wed Jun 29 20:51:06 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 29 Jun 2011 20:51:06 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29300 ] gem and require behavior changed Message-ID: <20110630005112.0A6331858361@rubyforge.org> Bugs item #29300, was opened at 2011-06-29 21:36 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29300&group_id=126 Category: #gem and #require methods Group: None Status: Open Resolution: None Priority: 3 Submitted By: Tom Trebisky (trebisky) Assigned to: Nobody (None) Summary: gem and require behavior changed Initial Comment: Once upon a time I had a script that worked, it used activerecord and pulled in that gem via the 3 lines: require "rubygems" gem "activerecord" require "activerecord" Now the script fails with /usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:53:in `gem_original_require': no such file to load -- activerecord (LoadError) from /usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:53:in `require' But I have a working rails install, so I know activerecord is on my system and healthy. After hours and hours of frustration, I find I can fix things by changing the above 3 lines to: require "rubygems" require "active_record" My take on this is that the behavior of the gem commands changed (I am now using rubygems 1.8.5, but 1.7.2 exhibited the same breakage). In the good old days, the gem command activated the activerecord gem and did some magic so the require would work (despite the unfortunately different naming of the file providing the gem). Maybe somebody decided that the magic was a bad idea? ---------------------------------------------------------------------- Comment By: Luis Lavena (luislavena) Date: 2011-06-29 21:51 Message: Hi! Believe it or not, we're moving to github's issue tracker! The pressure to move has been loud and clear, but for the longest time it didn't support the way we worked. Now that it has freeform labels it can support our workflow adequately. There is just one problem: Your bug is here and we don't want to lose you! What we'd like you to do is fairly painless and should only take a few minutes: Please file the _exact_ same ticket on github and provide a link back to this crufty old ticket so we can refer to any previous discussion that occurred. Once the new ticket is made, put a forwarding link to it here and close this ticket out. In a couple weeks, we'll track down the old tickets that are still open and decide what to do with them. We could have done this fairly automatically, but we really want you to do it so you're attached to the ticket and we can still communicate with you and keep a record of it. https://github.com/rubygems/rubygems/issues Thanks, The RubyGems Team ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29300&group_id=126 From noreply at rubyforge.org Wed Jun 29 20:51:33 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 29 Jun 2011 20:51:33 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29300 ] gem and require behavior changed Message-ID: <20110630005133.B425C1858361@rubyforge.org> Bugs item #29300, was opened at 2011-06-30 00:36 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29300&group_id=126 Category: #gem and #require methods Group: None Status: Open Resolution: None Priority: 3 Submitted By: Tom Trebisky (trebisky) Assigned to: Nobody (None) Summary: gem and require behavior changed Initial Comment: Once upon a time I had a script that worked, it used activerecord and pulled in that gem via the 3 lines: require "rubygems" gem "activerecord" require "activerecord" Now the script fails with /usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:53:in `gem_original_require': no such file to load -- activerecord (LoadError) from /usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:53:in `require' But I have a working rails install, so I know activerecord is on my system and healthy. After hours and hours of frustration, I find I can fix things by changing the above 3 lines to: require "rubygems" require "active_record" My take on this is that the behavior of the gem commands changed (I am now using rubygems 1.8.5, but 1.7.2 exhibited the same breakage). In the good old days, the gem command activated the activerecord gem and did some magic so the require would work (despite the unfortunately different naming of the file providing the gem). Maybe somebody decided that the magic was a bad idea? ---------------------------------------------------------------------- Comment By: Steve Klabnik (steveklabnik) Date: 2011-06-30 00:51 Message: Uhhhh... ActiveRecord changed the name to active_record with 3.0.x, IIRC. I'm not sure this has anything to do with Rubygems. ---------------------------------------------------------------------- Comment By: Luis Lavena (luislavena) Date: 2011-06-30 00:51 Message: Hi! Believe it or not, we're moving to github's issue tracker! The pressure to move has been loud and clear, but for the longest time it didn't support the way we worked. Now that it has freeform labels it can support our workflow adequately. There is just one problem: Your bug is here and we don't want to lose you! What we'd like you to do is fairly painless and should only take a few minutes: Please file the _exact_ same ticket on github and provide a link back to this crufty old ticket so we can refer to any previous discussion that occurred. Once the new ticket is made, put a forwarding link to it here and close this ticket out. In a couple weeks, we'll track down the old tickets that are still open and decide what to do with them. We could have done this fairly automatically, but we really want you to do it so you're attached to the ticket and we can still communicate with you and keep a record of it. https://github.com/rubygems/rubygems/issues Thanks, The RubyGems Team ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29300&group_id=126 From noreply at rubyforge.org Wed Jun 29 20:53:11 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 29 Jun 2011 20:53:11 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29300 ] gem and require behavior changed Message-ID: <20110630005311.5BBF31858361@rubyforge.org> Bugs item #29300, was opened at 2011-06-29 21:36 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29300&group_id=126 Category: #gem and #require methods Group: None Status: Open Resolution: None Priority: 3 Submitted By: Tom Trebisky (trebisky) Assigned to: Nobody (None) Summary: gem and require behavior changed Initial Comment: Once upon a time I had a script that worked, it used activerecord and pulled in that gem via the 3 lines: require "rubygems" gem "activerecord" require "activerecord" Now the script fails with /usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:53:in `gem_original_require': no such file to load -- activerecord (LoadError) from /usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:53:in `require' But I have a working rails install, so I know activerecord is on my system and healthy. After hours and hours of frustration, I find I can fix things by changing the above 3 lines to: require "rubygems" require "active_record" My take on this is that the behavior of the gem commands changed (I am now using rubygems 1.8.5, but 1.7.2 exhibited the same breakage). In the good old days, the gem command activated the activerecord gem and did some magic so the require would work (despite the unfortunately different naming of the file providing the gem). Maybe somebody decided that the magic was a bad idea? ---------------------------------------------------------------------- >Comment By: Luis Lavena (luislavena) Date: 2011-06-29 21:53 Message: Hello, RubyGems tracker as moved to GitHub: https://github.com/rubygems/rubygems/issues This was intentionally disabled from the the interface but seems you had a permalink to it. Either way: Which version of ActiveRecord are you talking about? Asking this because ActiveRecord from long ago was distributed as "activerecord" gem but the require is "active_record", as you can see in the source code by yourself (just do a gem unpack activerecord and check lib directory) Hope that helps. ---------------------------------------------------------------------- Comment By: Steve Klabnik (steveklabnik) Date: 2011-06-29 21:51 Message: Uhhhh... ActiveRecord changed the name to active_record with 3.0.x, IIRC. I'm not sure this has anything to do with Rubygems. ---------------------------------------------------------------------- Comment By: Luis Lavena (luislavena) Date: 2011-06-29 21:51 Message: Hi! Believe it or not, we're moving to github's issue tracker! The pressure to move has been loud and clear, but for the longest time it didn't support the way we worked. Now that it has freeform labels it can support our workflow adequately. There is just one problem: Your bug is here and we don't want to lose you! What we'd like you to do is fairly painless and should only take a few minutes: Please file the _exact_ same ticket on github and provide a link back to this crufty old ticket so we can refer to any previous discussion that occurred. Once the new ticket is made, put a forwarding link to it here and close this ticket out. In a couple weeks, we'll track down the old tickets that are still open and decide what to do with them. We could have done this fairly automatically, but we really want you to do it so you're attached to the ticket and we can still communicate with you and keep a record of it. https://github.com/rubygems/rubygems/issues Thanks, The RubyGems Team ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29300&group_id=126 From noreply at rubyforge.org Wed Jun 29 20:57:41 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 29 Jun 2011 20:57:41 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29300 ] gem and require behavior changed Message-ID: <20110630005741.665A41858361@rubyforge.org> Bugs item #29300, was opened at 2011-06-29 21:36 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29300&group_id=126 Category: #gem and #require methods Group: None >Status: Closed >Resolution: Rejected Priority: 3 Submitted By: Tom Trebisky (trebisky) Assigned to: Nobody (None) Summary: gem and require behavior changed Initial Comment: Once upon a time I had a script that worked, it used activerecord and pulled in that gem via the 3 lines: require "rubygems" gem "activerecord" require "activerecord" Now the script fails with /usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:53:in `gem_original_require': no such file to load -- activerecord (LoadError) from /usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:53:in `require' But I have a working rails install, so I know activerecord is on my system and healthy. After hours and hours of frustration, I find I can fix things by changing the above 3 lines to: require "rubygems" require "active_record" My take on this is that the behavior of the gem commands changed (I am now using rubygems 1.8.5, but 1.7.2 exhibited the same breakage). In the good old days, the gem command activated the activerecord gem and did some magic so the require would work (despite the unfortunately different naming of the file providing the gem). Maybe somebody decided that the magic was a bad idea? ---------------------------------------------------------------------- >Comment By: Luis Lavena (luislavena) Date: 2011-06-29 21:57 Message: Closing this out as appears to be a gem issue and not RubyGems itself. Please feel free to open a Issue on GitHub: https://github.com/rubygems/rubygems/issues ---------------------------------------------------------------------- Comment By: Luis Lavena (luislavena) Date: 2011-06-29 21:53 Message: Hello, RubyGems tracker as moved to GitHub: https://github.com/rubygems/rubygems/issues This was intentionally disabled from the the interface but seems you had a permalink to it. Either way: Which version of ActiveRecord are you talking about? Asking this because ActiveRecord from long ago was distributed as "activerecord" gem but the require is "active_record", as you can see in the source code by yourself (just do a gem unpack activerecord and check lib directory) Hope that helps. ---------------------------------------------------------------------- Comment By: Steve Klabnik (steveklabnik) Date: 2011-06-29 21:51 Message: Uhhhh... ActiveRecord changed the name to active_record with 3.0.x, IIRC. I'm not sure this has anything to do with Rubygems. ---------------------------------------------------------------------- Comment By: Luis Lavena (luislavena) Date: 2011-06-29 21:51 Message: Hi! Believe it or not, we're moving to github's issue tracker! The pressure to move has been loud and clear, but for the longest time it didn't support the way we worked. Now that it has freeform labels it can support our workflow adequately. There is just one problem: Your bug is here and we don't want to lose you! What we'd like you to do is fairly painless and should only take a few minutes: Please file the _exact_ same ticket on github and provide a link back to this crufty old ticket so we can refer to any previous discussion that occurred. Once the new ticket is made, put a forwarding link to it here and close this ticket out. In a couple weeks, we'll track down the old tickets that are still open and decide what to do with them. We could have done this fairly automatically, but we really want you to do it so you're attached to the ticket and we can still communicate with you and keep a record of it. https://github.com/rubygems/rubygems/issues Thanks, The RubyGems Team ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29300&group_id=126