From luislavena at gmail.com Tue May 3 21:23:24 2011 From: luislavena at gmail.com (Luis Lavena) Date: Tue, 3 May 2011 22:23:24 -0300 Subject: [Rubygems-developers] Prepping for release? Message-ID: Saw this commit: https://github.com/rubygems/rubygems/commit/aa4bd18e93d7de7124d12f9c185be7474a55bc4d I can say things are not that green on Windows: ruby 1.9.2p180 (2011-02-18) [i386-mingw32] 844 tests, 1823 assertions, 0 failures, 338 errors, 17 skips Don't have the time to check tonight, so hope you guys are not thinking on doing a release without giving me enough heads up for a proper check. 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 erik at hollensbe.org Wed May 4 01:34:24 2011 From: erik at hollensbe.org (Erik Hollensbe) Date: Wed, 4 May 2011 01:34:24 -0400 Subject: [Rubygems-developers] Prepping for release? In-Reply-To: References: Message-ID: <086A0D53-B215-4660-9AA5-554C6D5A160B@hollensbe.org> Luis, I'll see if I can chip in a little effort tomorrow evening to get these issues resolved, I should have some time and need to familiarize myself with the recent changes anyhow. -Erik On May 3, 2011, at 9:23 PM, Luis Lavena wrote: > Saw this commit: > https://github.com/rubygems/rubygems/commit/aa4bd18e93d7de7124d12f9c185be7474a55bc4d > > I can say things are not that green on Windows: > > ruby 1.9.2p180 (2011-02-18) [i386-mingw32] > 844 tests, 1823 assertions, 0 failures, 338 errors, 17 skips > > Don't have the time to check tonight, so hope you guys are not > thinking on doing a release without giving me enough heads up for a > proper check. > > 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 > _______________________________________________ > Rubygems-developers mailing list > http://rubyforge.org/projects/rubygems > Rubygems-developers at rubyforge.org > http://rubyforge.org/mailman/listinfo/rubygems-developers From lsegal at soen.ca Wed May 4 01:35:31 2011 From: lsegal at soen.ca (Loren Segal) Date: Wed, 04 May 2011 01:35:31 -0400 Subject: [Rubygems-developers] has_rdoc deprecation and alternatives? In-Reply-To: <4DAC04BB.5010406@soen.ca> References: <4D9A1937.8000906@soen.ca> <3144FD33-9304-44CD-8CCF-B0247001AAE1@segment7.net> <4D9BAB90.7050204@soen.ca> <63E61171-D8D5-4448-A3EB-A8768C8DE60A@segment7.net> <4DA4A60D.7030804@soen.ca> <4DAC04BB.5010406@soen.ca> Message-ID: <4DC0E5A3.3080305@soen.ca> On 4/18/2011 5:30 AM, Loren Segal wrote: > > > On 4/12/2011 3:20 PM, Loren Segal wrote: >>>> Again, I'd really opt for the extra docs package, I think it's the >>>> way to go and solves more of the problems than post install hooks. >>>> That said, I think your solution should be implemented as well, and >>>> should be the fallback. ie. RubyGems should look for a static docs >>>> packaged-- but if not present, we can use the great post install >>>> hook idea with --document, etc. >>> I recommend implementing static documentation as a plugin to >>> rubygems. If it becomes a proven solution it can be merged in. >> >> Thanks, I will look into using the new post install hooks then. >> >> In this case, is there a way to disable another "post install hook" >> from running? For instance, if a static documentation plugin ran, we >> would want to disable RDoc/RI from generating. Is this feasible with >> the APIs, or do we have to resort to unsupported monkeypatching again? > > Is there any followup on this? It would be fairly important to have > this kind of functionality in order to add proper YARD support, and/or > generalized support for "skipping" the doc generation process and > downloading static doc tarballs via a plugin. > > Perhaps RDoc/RI themselves should be installing post install hooks > like everybody else. That way, at least they could be unregistered by > other plugins. > > I'm not sure if API is still being developed; if so, it would be nice > to have this scenario as a consideration (if it isn't already being > considered). Here's my last attempt at getting a response to this. If not, I guess we'll just have to go back to square one and monkey patch Rubygems to work the way we need it to. Given that the 1.8.0 release is impending, I trust that the API dust is settling, which is either a good or bad thing, depending on if there's support for cancelling the RDoc/RI hooks from running. So, again, is this possible through RubyGems' new post install hook API? To summarize the issue: implementing a static documentation downloader RG plugin would require that no documentation be generated locally regardless of the `--document` setting (only --no-rdoc setting would be useful). The point would be to download the archive from a remote server and bypass local doc tools. I currently don't see any way to easily do this from a post install hook, since RDoc/RI aren't themselves post install hooks. The only other thing I could think of (besides monkeypatching) would be to forcibly add `--document mytool` to the .gemrc upon post_install of the plugin, but that doesn't sound like an easy or proper thing to do. - Loren From ryand-ruby at zenspider.com Wed May 4 11:51:52 2011 From: ryand-ruby at zenspider.com (Ryan Davis) Date: Wed, 4 May 2011 08:51:52 -0700 Subject: [Rubygems-developers] Prepping for release? In-Reply-To: References: Message-ID: On May 3, 2011, at 18:23 , Luis Lavena wrote: > Saw this commit: > https://github.com/rubygems/rubygems/commit/aa4bd18e93d7de7124d12f9c185be7474a55bc4d > > I can say things are not that green on Windows: > > ruby 1.9.2p180 (2011-02-18) [i386-mingw32] > 844 tests, 1823 assertions, 0 failures, 338 errors, 17 skips > > Don't have the time to check tonight, so hope you guys are not > thinking on doing a release without giving me enough heads up for a > proper check. My fault. I took a shortcut I shouldn't have taken. I'm now getting: > 821 tests, 2644 assertions, 1 failures, 5 errors, 21 skips the 1/5 are all related to configure/make and presumably pass when I have a proper development environment. I'm a windows newb and that's currently beyond me. Frankly, I'm amazed I got this far (I'm even running autotest on cmd inside of emacs!). I've pushed a fix. Related: Do we have access to any resources to run a CI on windows? I really don't want to have to fire up vmware often. From erik at hollensbe.org Wed May 4 13:02:23 2011 From: erik at hollensbe.org (Erik Hollensbe) Date: Wed, 4 May 2011 13:02:23 -0400 Subject: [Rubygems-developers] Prepping for release? In-Reply-To: References: Message-ID: <1B7AE883-71DB-4829-89EC-387491D772C5@hollensbe.org> I have temporary resources (working on that CI thing for gem-testers... have a beefy box that's dedicated to it, but the system isn't finished yet) that we could use for the meantime. IOW, if someone has a more permanent solution, great, but if not, I can help. -Erik On May 4, 2011, at 11:51 AM, Ryan Davis wrote: > > On May 3, 2011, at 18:23 , Luis Lavena wrote: > >> Saw this commit: >> https://github.com/rubygems/rubygems/commit/aa4bd18e93d7de7124d12f9c185be7474a55bc4d >> >> I can say things are not that green on Windows: >> >> ruby 1.9.2p180 (2011-02-18) [i386-mingw32] >> 844 tests, 1823 assertions, 0 failures, 338 errors, 17 skips >> >> Don't have the time to check tonight, so hope you guys are not >> thinking on doing a release without giving me enough heads up for a >> proper check. > > My fault. I took a shortcut I shouldn't have taken. I'm now getting: > >> 821 tests, 2644 assertions, 1 failures, 5 errors, 21 skips > > the 1/5 are all related to configure/make and presumably pass when I have a proper development environment. I'm a windows newb and that's currently beyond me. Frankly, I'm amazed I got this far (I'm even running autotest on cmd inside of emacs!). I've pushed a fix. > > Related: Do we have access to any resources to run a CI on windows? I really don't want to have to fire up vmware often. > > _______________________________________________ > 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 May 4 17:36:33 2011 From: drbrain at segment7.net (Eric Hodel) Date: Wed, 4 May 2011 14:36:33 -0700 Subject: [Rubygems-developers] [ANN] rubygems-update 1.8.0 Message-ID: <92BEEA66-1F14-4587-B4C0-309EBDFC525F@segment7.net> rubygems-update version 1.8.0 has been released! * * * * * RubyGems is a package management framework for Ruby. This gem is an update for the RubyGems software. You must have an installation of RubyGems before this update can be applied. See Gem for information on RubyGems (or `ri Gem`) To upgrade to the latest RubyGems, run: $ gem update --system # you might need to be an administrator or root See UPGRADING.rdoc for more details and alternative instructions. ----- If you don't have RubyGems installed, your can still do it manually: * Download from: https://rubygems.org/pages/download * Unpack into a directory and cd there * Install with: ruby setup.rb # you may need admin/root privilege For more details and other options, see: ruby setup.rb --help === 1.8.0 / 2011-04-34 This release focused on properly encapsulating functionality. Most of this work focused on moving functionality out of Gem::SourceIndex and Gem::GemPathSearcher into Gem::Specification where it belongs. After installing RubyGems 1.8.0 you will see deprecations when loading your exsting gems. Run `gem pristine --all --no-extensions` to regenerate your gem specifications safely. Currently RubyGems does not save the build arguments used to build gems with extensions. You will need to run `gem pristine gem_with_extension -- --build-arg` to regenerate a gem with an extension where it requires special build arguments. See also: http://blog.zenspider.com/2011/05/rubygems-18-is-coming.html * 24(+) Deprecations (WOOT!): * DependencyList.from_source_index deprecated the source_index argument. * Deprecated Dependency.new(/regex/). * Deprecated Gem.searcher. * Deprecated Gem.source_index and Gem.available? * Deprecated Gem: activate_dep, activate_spec, activate, report_activate_error, and required_location. * Deprecated Gem::all_partials * Deprecated Gem::cache_dir * Deprecated Gem::cache_gem * Deprecated Gem::default_system_source_cache_dir * Deprecated Gem::default_user_source_cache_dir * Deprecated Platform#empty? * Deprecated Specification.cache_gem * Deprecated Specification.installation_path * Deprecated Specification.loaded, loaded?, and loaded= * Deprecated all of Gem::SourceIndex. * Deprecated all of Gem::GemPathSearcher. * Deprecated Gem::Specification#default_executable. * 2 major enhancements: * Gem::SourceIndex functionality has been moved to Gem::Specification. Gem::SourceIndex is completely disconnected from Gem::Specification * Refactored GemPathSearcher entirely out. RIPMF * 41 minor enhancements: * Added CommandManager#unregister_command * Added Dependency#matching_specs + to_specs. * Added Dependency#to_spec * Added Gem.pre_reset_hook/s and post_reset_hook/s. * Added GemCommand.reset to reinitialize the singleton * Added Specification#activate. * Added Specification#activated, activated=, and activated? * Added Specification#base_dir. * Added Specification#bin_dir and bin_file. * Added Specification#cache_dir and cache_file. Aliased cache_gem. * Added Specification#doc_dir and ri_dir. * Added Specification#find(name_or_dep, *requirements). * Added Specification#gem_dir and gems_dir. * Added Specification#spec_dir and spec_file. * Added Specification.add_spec, add_specs, and remove_spec. * Added Specification.all=. If you use this, we will light you on fire. * Added Specification.all_names. * Added Specification.dirs and dirs=. dirs= resets. * Added Specification.find_all_by_name(name, *reqs) * Added Specification.latest_specs. SO TINY! * Added TestCase#all_spec_names to help clean up tests * Added TestCase#assert_path_exists and refute_path_exists. Will move to minitest. * Gem.sources no longer tries to load sources gem. Only uses default_sources. * Installer no longer accepts a source_index option. * More low-level integration. * Removed Gem::FileOperations since it is a dummy class * Removed a comment because I am dumb * Removed pkgs/sources/lib/sources.rb * Revamped indexer to mostly not use SourceIndex (legacy index requires it). * Rewrote our last functional test suite to be happy and fast * RubyGems is now under the Ruby License or the MIT license * Specification#== now only checks name, version, and platform. * Specification#authors= now forcefully flattens contents (bad rspec! no cookie!) * Specification#eql? checks all fields. * Specification#installation_path no longer raises if it hasn't been activated. * Specification#validate now ensures that authors is not empty. * TestCase.util_setup_spec_fetcher no longer returns a SourceIndex. * Uninstaller no longer passes around SourceIndex instances * Warn on loading bad spec array values (ntlm-http gem has nil in its cert chain) * `gem pristine` now accepts --no-executables to skip restoring gems with extensions. * `gem pristine` can now restore multiple gems. * 6 bug fixes: * DependencyInstaller passed around a source_index instance but used Gem.source_index. * Fixed Platform#== and #hash so instances may be used as hash keys. * Fixed broken Specification#original_platform. It should never be nil. * Gem::Text#format_text now strips trailing whitespace * Normalize LOAD_PATH with File.expand_path * `gem build` errors should exit 1. * `gem pristine` can now restore non-latest gems where the cached gem was removed. From noreply at rubyforge.org Wed May 4 19:14:00 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 4 May 2011 19:14:00 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29163 ] Invalid specs resulting from incorrect syck time parsing Message-ID: <20110504231400.99199185836B@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: Open Resolution: None Priority: 3 Submitted By: Bruno Michel (nono) Assigned to: Nobody (None) 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 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29163&group_id=126 From luislavena at gmail.com Wed May 4 19:55:43 2011 From: luislavena at gmail.com (Luis Lavena) Date: Wed, 4 May 2011 20:55:43 -0300 Subject: [Rubygems-developers] Indexer bug on Windows, where to commit? Message-ID: Hello, It is not clear to me if a bugfix should first need to be committed to master and then backported to 1.8 branch or viceversa? Indexer is broken due a typo on Windows, that single typo solved all the test_gem_indexer tests: C:\Users\Luis\Projects\oss\rubygems>git diff diff --git a/lib/rubygems/indexer.rb b/lib/rubygems/indexer.rb index db823d7..23c0167 100644 --- a/lib/rubygems/indexer.rb +++ b/lib/rubygems/indexer.rb @@ -80,7 +80,7 @@ class Gem::Indexer @master_index = File.join @directory, 'yaml' @marshal_index = File.join @directory, marshal_name - @quick_dir = File.join, @directory, 'quick' + @quick_dir = File.join @directory, 'quick' @quick_marshal_dir = File.join @quick_dir, marshal_name @quick_marshal_dir_base = File.join "quick", marshal_name # FIX: UGH === Still remains another test to fix which seems invalid generation of gem metadata, will investigate. Hints on workflow? 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 luislavena at gmail.com Wed May 4 20:35:33 2011 From: luislavena at gmail.com (Luis Lavena) Date: Wed, 4 May 2011 21:35:33 -0300 Subject: [Rubygems-developers] Windows: all green Message-ID: Happy to inform that pushed some changes to master and now everything is green: ruby 1.9.2p180 (2011-02-18) [i386-mingw32] 850 tests, 2819 assertions, 0 failures, 0 errors, 21 skips ruby 1.8.7 (2011-02-18 patchlevel 334) [i386-mingw32] 850 tests, 2821 assertions, 0 failures, 0 errors, 19 skips -- 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 May 4 21:42:24 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 4 May 2011 21:42:24 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29116 ] Mega slowness in custom require Message-ID: <20110505014224.A6D051858374@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-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 Thu May 5 00:12:53 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 5 May 2011 00:12:53 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Feature Requests-29165 ] rubygems-update appears to have deprecated hooks after updating rubygems Message-ID: <20110505041253.32667185836B@rubyforge.org> Feature Requests item #29165, was opened at 2011-05-05 04:12 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=578&aid=29165&group_id=126 Category: `gem` commands Group: None Status: Open Resolution: None Priority: 3 Submitted By: denny abraham (dennyabraham) Assigned to: Nobody (None) Summary: rubygems-update appears to have deprecated hooks after updating rubygems Initial Comment: after updating rubygems to 1.8, rubygems-update-1.8 shows the following deprecation warning 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/dennyabraham/.rvm/gems/ruby-1.9.2-p180/specifications/rubygems-update-1.8.0.gemspec:11. on completion, rubygems-update should regenerate at least its own specifications, but ideally all outdated specs possible. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=578&aid=29165&group_id=126 From noreply at rubyforge.org Thu May 5 03:34:21 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 5 May 2011 03:34:21 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29166 ] gem installs dependencies for gems it never installed Message-ID: <20110505073421.B87011858374@rubyforge.org> Bugs item #29166, was opened at 2011-05-05 00: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: Open Resolution: None Priority: 3 Submitted By: Greg Hazel (ghazel) Assigned to: Nobody (None) 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? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29166&group_id=126 From noreply at rubyforge.org Thu May 5 08:22:57 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 5 May 2011 08:22:57 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29166 ] gem installs dependencies for gems it never installed Message-ID: <20110505122257.981E9185836C@rubyforge.org> Bugs item #29166, was opened at 2011-05-05 04: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: Open Resolution: None Priority: 3 Submitted By: Greg Hazel (ghazel) Assigned to: Nobody (None) 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: Luis Lavena (luislavena) Date: 2011-05-05 09: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 Thu May 5 08:28:17 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 5 May 2011 08:28:17 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29166 ] gem installs dependencies for gems it never installed Message-ID: <20110505122817.8C4EB1858374@rubyforge.org> Bugs item #29166, was opened at 2011-05-05 00: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: Open Resolution: None Priority: 3 Submitted By: Greg Hazel (ghazel) Assigned to: Nobody (None) 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: Greg Hazel (ghazel) Date: 2011-05-05 05: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 05: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 Thu May 5 08:32:53 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 5 May 2011 08:32:53 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29166 ] gem installs dependencies for gems it never installed Message-ID: <20110505123255.9A0C21858374@rubyforge.org> Bugs item #29166, was opened at 2011-05-05 04: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: Open Resolution: None Priority: 3 Submitted By: Greg Hazel (ghazel) >Assigned to: Ryan Davis (zenspider) 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: Greg Hazel (ghazel) Date: 2011-05-05 09: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 09: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 Thu May 5 11:12:10 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 5 May 2011 11:12:10 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-28839 ] File not found: README when upgrading to 1.4.2 Message-ID: <20110505151210.E2CEA185834E@rubyforge.org> Bugs item #28839, was opened at 2011-01-09 06:07 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28839&group_id=126 Category: other Group: v1.4.x Status: Closed Resolution: None Priority: 3 Submitted By: Daniel Berger (djberg96) Assigned to: Ryan Davis (zenspider) Summary: File not found: README when upgrading to 1.4.2 Initial Comment: I saw this warning when I updated from rubygems 1.3.5 to 1.4.2 on FreeBSD 7, with ruby 1.8.6: File not found: README Regards, Dan ---------------------------------------------------------------------- Comment By: Mike Bailey (deprecated) Date: 2011-05-06 01:12 Message: This exits with an error condition on lucid 32bit. This is causing Capistrano to bomb out. root at ct-lucid32:/usr/local/src/rubygems-1.4.2# sudo -p 'sudo password: ' ruby setup.rb; RubyGems 1.4.2 installed File not found: README root at ct-lucid32:/usr/local/src/rubygems-1.4.2# echo $? 1 # My environment root at ct-lucid32:/usr/local/src/rubygems-1.4.2# ruby --version ruby 1.8.7 (2011-02-18 patchlevel 334) [i686-linux], MBARI 0x8770, Ruby Enterprise Edition 2011.03 root at ct-lucid32:/usr/local/src/rubygems-1.4.2# gem --version 1.4.2 root at ct-lucid32:/usr/local/src/rubygems-1.4.2# cat /etc/lsb-release DISTRIB_ID=Ubuntu DISTRIB_RELEASE=10.04 DISTRIB_CODENAME=lucid DISTRIB_DESCRIPTION="Ubuntu 10.04.2 LTS" ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-01-09 19:10 Message: OK. The problem is that the 1.3.7 and below had README and we switched up to README.rdoc in 1.4.0. 4123 % gem spec rubygems-update -v 1.3.5 | grep README - README - README 4124 % gem spec rubygems-update -v 1.3.7 | grep README - README - README 4125 % gem spec rubygems-update -v 1.4.2 | grep README - README.rdoc - README.rdoc - README.rdoc 4129 % gem update --system Updating RubyGems Updating rubygems-update Successfully installed rubygems-update-1.4.2 Updating RubyGems to 1.4.2 Installing RubyGems 1.4.2 RubyGems 1.4.2 installed File not found: README 4130 % echo $? 0 Since this is just a warning and only for rdoc (it won't affect RI info), I'm gonna go ahead and close this bug. Feel free to reopen if you feel I'm missing something. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-01-09 19:05 Message: rdoc problem Installing RDoc documentation for rubygems-update-1.3.7... Could not find main page README Could not find main page README Could not find main page README Could not find main page README ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28839&group_id=126 From noreply at rubyforge.org Thu May 5 12:46:17 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 5 May 2011 12:46:17 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29168 ] gem install gives vague error when not connected to network Message-ID: <20110505164617.3EFEE1858376@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: Open Resolution: None Priority: 3 Submitted By: Bala Paranj (bparanj) Assigned to: Nobody (None) Summary: gem install 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 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29168&group_id=126 From noreply at rubyforge.org Thu May 5 12:58:10 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 5 May 2011 12:58:10 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29168 ] gem install gives vague error when not connected to network Message-ID: <20110505165810.E034E185838A@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: Open Resolution: None Priority: 3 Submitted By: Bala Paranj (bparanj) >Assigned to: Evan Phoenix (evan) Summary: gem install 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-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 Thu May 5 13:11:41 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 5 May 2011 13:11:41 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29168 ] gem install < gem_name> gives vague error when not connected to network Message-ID: <20110505171141.BD3C01858376@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: Open 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: 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 Thu May 5 13:14:16 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 5 May 2011 13:14:16 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29168 ] gem install & lt; gem_name& gt; gives vague error when not connected to network Message-ID: <20110505171416.8B9841858376@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: Open Resolution: None Priority: 3 Submitted By: Bala Paranj (bparanj) Assigned to: Evan Phoenix (evan) >Summary: gem install &lt;gem_name&gt; 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: 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 Thu May 5 13:18:05 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 5 May 2011 13:18:05 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29166 ] gem installs dependencies for gems it never installed Message-ID: <20110505171805.CE6BE1858376@rubyforge.org> Bugs item #29166, was opened at 2011-05-05 00: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: Open >Resolution: Accepted >Priority: 5 Submitted By: Greg Hazel (ghazel) >Assigned to: Eric Hodel (drbrain) 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: Ryan Davis (zenspider) Date: 2011-05-05 10: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 05: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 05: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 Thu May 5 13:18:22 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 5 May 2011 13:18:22 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29168 ] gem install & amp; lt; gem_name& amp; gt; gives vague error when not connected to network Message-ID: <20110505171822.C3BE2185838E@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: Open Resolution: None Priority: 3 Submitted By: Bala Paranj (bparanj) Assigned to: Evan Phoenix (evan) >Summary: gem install &amp;lt;gem_name&amp;gt; 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: 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 Thu May 5 14:56:18 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 5 May 2011 14:56:18 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29166 ] gem installs dependencies for gems it never installed Message-ID: <20110505185618.79039185838A@rubyforge.org> Bugs item #29166, was opened at 2011-05-05 00: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: Open Resolution: Accepted Priority: 5 Submitted By: Greg Hazel (ghazel) Assigned to: Eric Hodel (drbrain) 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: Eric Hodel (drbrain) Date: 2011-05-05 11: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 10: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 05: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 05: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 Thu May 5 15:07:02 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 5 May 2011 15:07:02 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29168 ] gem install gem_name gives vague error when not connected to network Message-ID: <20110505190702.C6B1E185838A@rubyforge.org> Bugs item #29168, was opened at 2011-05-05 09:46 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29168&group_id=126 Category: None Group: None Status: Open 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: Bala Paranj (bparanj) Date: 2011-05-05 10: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 10: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 10: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 09: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 ryand-ruby at zenspider.com Thu May 5 15:13:25 2011 From: ryand-ruby at zenspider.com (Ryan Davis) Date: Thu, 5 May 2011 12:13:25 -0700 Subject: [Rubygems-developers] Indexer bug on Windows, where to commit? In-Reply-To: References: Message-ID: <4C24FACB-655D-418B-98FE-9FB0E429454B@zenspider.com> On May 4, 2011, at 16:55 , Luis Lavena wrote: > It is not clear to me if a bugfix should first need to be committed to > master and then backported to 1.8 branch or viceversa? > > Indexer is broken due a typo on Windows, that single typo solved all > the test_gem_indexer tests: > > C:\Users\Luis\Projects\oss\rubygems>git diff > diff --git a/lib/rubygems/indexer.rb b/lib/rubygems/indexer.rb > index db823d7..23c0167 100644 > --- a/lib/rubygems/indexer.rb > +++ b/lib/rubygems/indexer.rb > @@ -80,7 +80,7 @@ class Gem::Indexer > @master_index = File.join @directory, 'yaml' > @marshal_index = File.join @directory, marshal_name > > - @quick_dir = File.join, @directory, 'quick' > + @quick_dir = File.join @directory, 'quick' > @quick_marshal_dir = File.join @quick_dir, marshal_name > @quick_marshal_dir_base = File.join "quick", marshal_name # FIX: UGH God our tests are lame... someday... This was discussed in IRC but I'll repeat it here: Please commit all fixes to master and we'll cut 1.8.1 from there. New features (erikh just added better output to gem list) should go there too, but for a couple days after a dot-oh should either not be pushed or should go to a feature branch. > Still remains another test to fix which seems invalid generation of > gem metadata, will investigate. thanks! From luislavena at gmail.com Thu May 5 15:42:14 2011 From: luislavena at gmail.com (Luis Lavena) Date: Thu, 5 May 2011 16:42:14 -0300 Subject: [Rubygems-developers] Indexer bug on Windows, where to commit? In-Reply-To: <4C24FACB-655D-418B-98FE-9FB0E429454B@zenspider.com> References: <4C24FACB-655D-418B-98FE-9FB0E429454B@zenspider.com> Message-ID: On Thu, May 5, 2011 at 4:13 PM, Ryan Davis wrote: > > > This was discussed in IRC but I'll repeat it here: > > Please commit all fixes to master and we'll cut 1.8.1 from there. > > New features (erikh just added better output to gem list) should go there too, but for a couple days after a dot-oh should either not be pushed or should go to a feature branch. > All sorted out, forgot to update the thread. Thanks, -- 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 Thu May 5 18:10:50 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 5 May 2011 18:10:50 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29166 ] gem installs dependencies for gems it never installed Message-ID: <20110505221050.4A28A1858377@rubyforge.org> Bugs item #29166, was opened at 2011-05-05 00: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: Open Resolution: Accepted Priority: 5 Submitted By: Greg Hazel (ghazel) Assigned to: Eric Hodel (drbrain) 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: Greg Hazel (ghazel) Date: 2011-05-05 15: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 11: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 10: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 05: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 05: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 Thu May 5 20:01:55 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 5 May 2011 20:01:55 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29166 ] gem installs dependencies for gems it never installed Message-ID: <20110506000155.7595E1858378@rubyforge.org> Bugs item #29166, was opened at 2011-05-05 00: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: Open Resolution: Accepted >Priority: 3 Submitted By: Greg Hazel (ghazel) >Assigned to: Ryan Davis (zenspider) 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: Ryan Davis (zenspider) Date: 2011-05-05 17: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 15: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 11: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 10: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 05: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 05: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 Thu May 5 21:56:13 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 5 May 2011 21:56:13 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29169 ] rake creates ruby wrappers around non-ruby executables, causing them to fail Message-ID: <20110506015613.36D95185837F@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: None Priority: 3 Submitted By: Kevin Olbrich (olbrich) Assigned to: Nobody (None) 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 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29169&group_id=126 From noreply at rubyforge.org Thu May 5 23:40:09 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 5 May 2011 23:40:09 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29170 ] with multiple sources, if one is unavailable, nothing works at all Message-ID: <20110506034010.079ED185837F@rubyforge.org> Bugs item #29170, was opened at 2011-05-05 22: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: None Priority: 3 Submitted By: Nick Klauer (klauern) Assigned to: Nobody (None) 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? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29170&group_id=126 From noreply at rubyforge.org Fri May 6 05:30:22 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 6 May 2011 05:30:22 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29171 ] spork fails to work with rubygems 1.8.0/1.8.1 but works with 1.7.2 Message-ID: <20110506093022.58C6C185837F@rubyforge.org> Bugs item #29171, was opened at 2011-05-06 15:00 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29171&group_id=126 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Bhavin Kamani (beekay) Assigned to: Nobody (None) Summary: spork fails to work with rubygems 1.8.0/1.8.1 but works with 1.7.2 Initial Comment: After doing a system upgrade spork fails to work with 1.8.0/1.8.1. It appears to be rubygems issue as stacktrace (https://gist.github.com/956888) leads to a rubygem deprecated method "latest_load_paths". All works well when I revert back to 1.7.2 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29171&group_id=126 From noreply at rubyforge.org Fri May 6 08:42:55 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 6 May 2011 08:42:55 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Feature Requests-29172 ] feature request: super verbose install output Message-ID: <20110506124256.5F71018583A2@rubyforge.org> Feature Requests item #29172, was opened at 2011-05-06 12:42 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=578&aid=29172&group_id=126 Category: `gem install` command Group: None Status: Open Resolution: None Priority: 3 Submitted By: Roger Pack (rogerdpack) Assigned to: Nobody (None) Summary: feature request: super verbose install output Initial Comment: Hello all. I know you can get to the "root" of a gem install via tracking down the log, which log mentions another log typically, if it included a native compile. So my request would be a slightly easier way to do this, ex: gem install failing_gem -vv or what not, which would dump to the screen all of the various outputs. Cheers! -r ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=578&aid=29172&group_id=126 From noreply at rubyforge.org Fri May 6 09:24:37 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 6 May 2011 09:24:37 -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: <20110506132438.21E471858377@rubyforge.org> Bugs item #29173, was opened at 2011-05-06 08: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: Nobody (None) 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. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29173&group_id=126 From noreply at rubyforge.org Fri May 6 12:33:34 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 6 May 2011 12:33:34 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29171 ] spork fails to work with rubygems 1.8.0/1.8.1 but works with 1.7.2 Message-ID: <20110506163334.5B9401858372@rubyforge.org> Bugs item #29171, was opened at 2011-05-06 02:30 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29171&group_id=126 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Bhavin Kamani (beekay) Assigned to: Nobody (None) Summary: spork fails to work with rubygems 1.8.0/1.8.1 but works with 1.7.2 Initial Comment: After doing a system upgrade spork fails to work with 1.8.0/1.8.1. It appears to be rubygems issue as stacktrace (https://gist.github.com/956888) leads to a rubygem deprecated method "latest_load_paths". All works well when I revert back to 1.7.2 ---------------------------------------------------------------------- Comment By: Tim Harper (timcharper) Date: 2011-05-06 09:33 Message: What can a gem author use in place of latest_load_paths? I'm currently using the method to auto discover peer plug-ins (such as Spork-testunit) and activate code in them. With latest_load_paths removed, it seems that I have to resort to scanning the gem paths myself? That's kind of a bummer, if you ask me. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29171&group_id=126 From noreply at rubyforge.org Fri May 6 14:45:15 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 6 May 2011 14:45:15 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Feature Requests-29175 ] gem deprecated command Message-ID: <20110506184518.AD50B185836C@rubyforge.org> Feature Requests item #29175, was opened at 2011-05-06 11:45 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=578&aid=29175&group_id=126 Category: `gem` commands Group: None Status: Open Resolution: None Priority: 3 Submitted By: John Fearnside (jwfearn) Assigned to: Nobody (None) Summary: gem deprecated command Initial Comment: Like 'gem outdated' but would list gems that are using deprecated-soon-to-be-removed calls or whatever. It would list which gems are offending, which deprecated call (or calls) it's using and, ideally, indicate if a newer, non-offending version is available. I would prefer to use something like this rather than endure the cavalcade of deprecation warnings. May I suggest a less voluminous warning text: "Warning, N gems are using deprecated features. Type 'gem deprecated' for more information". Where N is the number of offending gems. I would also prefer some sort of option to suppress those warnings entirely as they break many of my build tools. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=578&aid=29175&group_id=126 From noreply at rubyforge.org Fri May 6 16:07:10 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 6 May 2011 16:07:10 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29176 ] Scary warnings are scaring helpless developers who can't do a thing about it Message-ID: <20110506200710.E9F2D167816A@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: Nobody (None) 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. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29176&group_id=126 From noreply at rubyforge.org Fri May 6 16:22:34 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 6 May 2011 16:22:34 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29176 ] Scary warnings are scaring helpless developers who can't do a thing about it Message-ID: <20110506202234.E413F1858367@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: Nobody (None) 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: 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 May 6 16:27:30 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 6 May 2011 16:27:30 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29176 ] Scary warnings are scaring helpless developers who can't do a thing about it Message-ID: <20110506202731.A86241858367@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: Nobody (None) 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-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 May 6 16:38:23 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 6 May 2011 16:38:23 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29176 ] Scary warnings are scaring helpless developers who can't do a thing about it Message-ID: <20110506203823.546941858367@rubyforge.org> Bugs item #29176, was opened at 2011-05-06 17: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: Nobody (None) 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: Luis Lavena (luislavena) Date: 2011-05-06 17: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 17: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 17: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 drbrain at segment7.net Fri May 6 17:14:01 2011 From: drbrain at segment7.net (Eric Hodel) Date: Fri, 6 May 2011 14:14:01 -0700 Subject: [Rubygems-developers] [ANN] rubygems-update 1.8.1 Released Message-ID: <9CD592AD-A5AA-4918-B74A-452EA1406BD6@segment7.net> rubygems-update version 1.8.1 has been released! * http://rubygems.org * http://docs.rubygems.org * http://help.rubygems.org * http://github.com/rubygems * http://rubyforge.org/projects/rubygems RubyGems is a package management framework for Ruby. This gem is an update for the RubyGems software. You must have an installation of RubyGems before this update can be applied. See Gem for information on RubyGems (or `ri Gem`) To upgrade to the latest RubyGems, run: $ gem update --system # you might need to be an administrator or root See UPGRADING.rdoc for more details and alternative instructions. ----- If you don't have RubyGems installed, your can still do it manually: * Download from: https://rubygems.org/pages/download * Unpack into a directory and cd there * Install with: ruby setup.rb # you may need admin/root privilege For more details and other options, see: ruby setup.rb --help === 1.8.1 / 2011-05-05 After installing RubyGems 1.8.1 you will see deprecations when loading your exsting gems. Run `gem pristine --all --no-extensions` to regenerate your gem specifications safely. Currently RubyGems does not save the build arguments used to build gems with extensions. You will need to run `gem pristine gem_with_extension -- --build-arg` to regenerate a gem with an extension where it requires special build arguments. * 1 minor enhancement: * Added Gem::Requirement#specific? and Gem::Dependency#specific? * 4 bug fixes: * Typo on Indexer rendered it useless on Windows * `gem dep` can fetch remote dependencies for non-latest gems again. * `gem uninstall` with multiple versions no longer crashes with ArgumentError * Always use binary mode for File.open to keep Windows happy From noreply at rubyforge.org Fri May 6 17:31:56 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 6 May 2011 17:31:56 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29171 ] spork fails to work with rubygems 1.8.0/1.8.1 but works with 1.7.2 Message-ID: <20110506213156.7ECC31858367@rubyforge.org> Bugs item #29171, was opened at 2011-05-06 02:30 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29171&group_id=126 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Bhavin Kamani (beekay) Assigned to: Nobody (None) Summary: spork fails to work with rubygems 1.8.0/1.8.1 but works with 1.7.2 Initial Comment: After doing a system upgrade spork fails to work with 1.8.0/1.8.1. It appears to be rubygems issue as stacktrace (https://gist.github.com/956888) leads to a rubygem deprecated method "latest_load_paths". All works well when I revert back to 1.7.2 ---------------------------------------------------------------------- >Comment By: Ryan Davis (zenspider) Date: 2011-05-06 14:31 Message: So you're the one! :P I was wondering who used that call. Google codesearch came up with nothing. We don't have any tests on that function so it escaped the wrath of my last cleanup and is apparently currently (inadvertently) broken. We'll get a fix out for it in a bit but in the meantime, I want to address Tim's question about what to use. I don't know why latest_load_paths was added to rubygems, but I wouldn't use it for what you're doing in the first place. Use Gem.find_files instead. It was intended for exactly this purpose. The rdoc for it will point you in the right direction. You'd probably replace your detect_and_require as well as other_spork_gem_load_paths entirely with something like: Gem.find_files('spork/test_framework/*.rb').each do |path| require path end ---------------------------------------------------------------------- Comment By: Tim Harper (timcharper) Date: 2011-05-06 09:33 Message: What can a gem author use in place of latest_load_paths? I'm currently using the method to auto discover peer plug-ins (such as Spork-testunit) and activate code in them. With latest_load_paths removed, it seems that I have to resort to scanning the gem paths myself? That's kind of a bummer, if you ask me. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29171&group_id=126 From noreply at rubyforge.org Fri May 6 17:38:25 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 6 May 2011 17:38:25 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29171 ] spork fails to work with rubygems 1.8.0/1.8.1 but works with 1.7.2 Message-ID: <20110506213826.0AE831858372@rubyforge.org> Bugs item #29171, was opened at 2011-05-06 02:30 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29171&group_id=126 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Bhavin Kamani (beekay) Assigned to: Nobody (None) Summary: spork fails to work with rubygems 1.8.0/1.8.1 but works with 1.7.2 Initial Comment: After doing a system upgrade spork fails to work with 1.8.0/1.8.1. It appears to be rubygems issue as stacktrace (https://gist.github.com/956888) leads to a rubygem deprecated method "latest_load_paths". All works well when I revert back to 1.7.2 ---------------------------------------------------------------------- Comment By: Tim Harper (timcharper) Date: 2011-05-06 14:38 Message: Well, I feel silly :) Should have read the docs better... find_files is a MUCH better method. I ended up hacking around it by implementing my own latest_load_paths... but yes, find_files is much preferred. Thank you! ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-05-06 14:31 Message: So you're the one! :P I was wondering who used that call. Google codesearch came up with nothing. We don't have any tests on that function so it escaped the wrath of my last cleanup and is apparently currently (inadvertently) broken. We'll get a fix out for it in a bit but in the meantime, I want to address Tim's question about what to use. I don't know why latest_load_paths was added to rubygems, but I wouldn't use it for what you're doing in the first place. Use Gem.find_files instead. It was intended for exactly this purpose. The rdoc for it will point you in the right direction. You'd probably replace your detect_and_require as well as other_spork_gem_load_paths entirely with something like: Gem.find_files('spork/test_framework/*.rb').each do |path| require path end ---------------------------------------------------------------------- Comment By: Tim Harper (timcharper) Date: 2011-05-06 09:33 Message: What can a gem author use in place of latest_load_paths? I'm currently using the method to auto discover peer plug-ins (such as Spork-testunit) and activate code in them. With latest_load_paths removed, it seems that I have to resort to scanning the gem paths myself? That's kind of a bummer, if you ask me. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29171&group_id=126 From noreply at rubyforge.org Fri May 6 17:41:27 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 6 May 2011 17:41:27 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29176 ] Scary warnings are scaring helpless developers who can't do a thing about it Message-ID: <20110506214127.EC4FF185836C@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: Nobody (None) 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-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 May 6 18:04:39 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 6 May 2011 18:04:39 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29176 ] Scary warnings are scaring helpless developers who can't do a thing about it Message-ID: <20110506220440.17DBC18582EE@rubyforge.org> Bugs item #29176, was opened at 2011-05-06 17: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: Nobody (None) 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: Luis Lavena (luislavena) Date: 2011-05-06 19: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 18: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 17: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 17: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 17: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 May 6 18:39:43 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 6 May 2011 18:39:43 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29176 ] Scary warnings are scaring helpless developers who can't do a thing about it Message-ID: <20110506223944.0C39C167816A@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: 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 May 6 18:40:09 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 6 May 2011 18:40:09 -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: <20110506224009.CAC4318582EE@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-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 Sat May 7 09:42:36 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 7 May 2011 09:42:36 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29181 ] RubyGems date spec field causing issues Message-ID: <20110507134236.CA26A185836B@rubyforge.org> Bugs item #29181, was opened at 2011-05-07 10:42 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29181&group_id=126 Category: other Group: None Status: Open Resolution: None Priority: 5 Submitted By: Luis Lavena (luislavena) Assigned to: Ryan Davis (zenspider) Summary: RubyGems date spec field causing issues Initial Comment: A new gem just released by one of the RubyInstaller contributors generated this: http://groups.google.com/group/rubyinstaller/msg/6a0b05d51811f5bc A simple gem, generated with Ruby 1.9.2 causes date to be generated incorrectly: Ruby 1.9.2 with RubyGems 1.8.1 date: 2011-05-07 00:00:00.000000000Z Ruby 1.8.7 with RubyGems 1.8.1: date: 2011-05-07 00:00:00 Z Installing that gem causes this: Invalid gemspec in [C:/Users/Luis/.gem/ruby/x86-mingw32/1.8/specifications/autotest-snarl-0.0.2.gemspec]: invalid date format in specification: "2011-05-07 00:00:00.000000000Z" C:/Users/Luis/Tools/ruby/ruby-1.8.7-p334-i386-mingw32/lib/ruby/site_ruby/1.8/rubygems/specification.rb:277:in `_resort!': undefined method `name' for nil:NilClass (NoMethodError) Not during installation but later in the process. You can reproduce this using my simple gem here: https://github.com/luislavena/autotest-snarl I don't use anything that is not RubyGems and Rake to generate it (even use Gem::PackageTask) ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29181&group_id=126 From noreply at rubyforge.org Sat May 7 12:22:59 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 7 May 2011 12:22:59 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Feature Requests-29182 ] Disconnect cache directory from GEM_HOME Message-ID: <20110507162259.7A4AF185836B@rubyforge.org> Feature Requests item #29182, was opened at 07/05/2011 18:22 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=578&aid=29182&group_id=126 Category: local package management Group: None Status: Open Resolution: None Priority: 3 Submitted By: (zimbatm) Assigned to: Nobody (None) Summary: Disconnect cache directory from GEM_HOME Initial Comment: When working with multiple gem homes, it makes no sense downloading the same .gem files over and over again in the different directories. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=578&aid=29182&group_id=126 From noreply at rubyforge.org Sat May 7 12:27:11 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 7 May 2011 12:27:11 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Feature Requests-29183 ] Default to --user-install ? Message-ID: <20110507162711.6C92C185836B@rubyforge.org> Feature Requests item #29183, was opened at 07/05/2011 18:27 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=578&aid=29183&group_id=126 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: (zimbatm) Assigned to: Nobody (None) Summary: Default to --user-install ? Initial Comment: When the gem process cannot write to the system gem directory, why not default to the user's gem directory ? I don't pretend it's easy, but rubygems often defaults to things I don't want. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=578&aid=29183&group_id=126 From noreply at rubyforge.org Sun May 8 01:40:06 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 8 May 2011 01:40:06 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29176 ] Scary warnings are scaring helpless developers who can't do a thing about it Message-ID: <20110508054006.47370185836B@rubyforge.org> Bugs item #29176, was opened at 2011-05-06 20: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: Loren Segal (lsegal) Date: 2011-05-08 05: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 22: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 21: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 20: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 20: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 20: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 Sun May 8 02:19:58 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 8 May 2011 02:19:58 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29176 ] Scary warnings are scaring helpless developers who can't do a thing about it Message-ID: <20110508061958.DFC001858375@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: 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 Sun May 8 02:53:28 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 8 May 2011 02:53:28 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29176 ] Scary warnings are scaring helpless developers who can't do a thing about it Message-ID: <20110508065328.9C0EC1858374@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-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 Sun May 8 02:54:36 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 8 May 2011 02:54:36 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29176 ] Scary warnings are scaring helpless developers who can't do a thing about it Message-ID: <20110508065436.F2DD51858374@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-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 Sun May 8 02:57:19 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 8 May 2011 02:57:19 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29176 ] Scary warnings are scaring helpless developers who can't do a thing about it Message-ID: <20110508065719.8309A1858374@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: 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 Sun May 8 04:56:23 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 8 May 2011 04:56:23 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29176 ] Scary warnings are scaring helpless developers who can't do a thing about it Message-ID: <20110508085636.3D1A41858375@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-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 Sun May 8 12:40:31 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 8 May 2011 12:40:31 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29176 ] Scary warnings are scaring helpless developers who can't do a thing about it Message-ID: <20110508164031.2A2001858372@rubyforge.org> Bugs item #29176, was opened at 2011-05-06 20: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: Loren Segal (lsegal) Date: 2011-05-08 16: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 08:56 Message: No worries. ---------------------------------------------------------------------- Comment By: Justin Collins (presidentbeef) Date: 2011-05-08 06:57 Message: Sorry, my mistake. I didn't notice that gem was called out specifically. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-05-08 06: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-08 06: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-08 06: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-08 05: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 22: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 21: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 20: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 20: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 20: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 Sun May 8 14:43:33 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 8 May 2011 14:43:33 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29176 ] Scary warnings are scaring helpless developers who can't do a thing about it Message-ID: <20110508184333.B01241858375@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-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 Sun May 8 15:27:13 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 8 May 2011 15:27:13 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29184 ] NOTE: Gem::Specification#default_executable= is deprecated with no replacement. Message-ID: <20110508192713.4755A1858375@rubyforge.org> Bugs item #29184, was opened at 2011-05-08 12:27 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29184&group_id=126 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Greg Hazel (ghazel) Assigned to: Nobody (None) Summary: NOTE: Gem::Specification#default_executable= is deprecated with no replacement. Initial Comment: Upgraded from 1.7.2 to 1.8.1 and got lots of messages like: Gem::Specification#default_executable= called from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/gems/1.8/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. "With no replacement" is not a very useful message, since it's not clear how to resolve this. Also, tons of gems cause this warning, so maybe the deprecation is not such a great idea. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29184&group_id=126 From noreply at rubyforge.org Sun May 8 15:29:27 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 8 May 2011 15:29:27 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29185 ] NOTE: Gem::SourceIndex#refresh! is deprecated with no replacement. Message-ID: <20110508192927.438151858375@rubyforge.org> Bugs item #29185, was opened at 2011-05-08 12:29 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29185&group_id=126 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Greg Hazel (ghazel) Assigned to: Nobody (None) Summary: NOTE: Gem::SourceIndex#refresh! is deprecated with no replacement. Initial Comment: Upgraded from 1.7.2 to 1.8.1, got: NOTE: Gem::SourceIndex#refresh! is deprecated with no replacement. It will be removed on or after 2011-11-01. Gem::SourceIndex#refresh! called from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/gems/1.8/gems/rails-2.3.11/lib/rails/vendor_gem_source_index.rb:34. "deprecated with no replacement" is not a useful message, since it's not clear how to resolve it. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29185&group_id=126 From noreply at rubyforge.org Sun May 8 15:31:10 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 8 May 2011 15:31:10 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29186 ] NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. Message-ID: <20110508193110.952401858375@rubyforge.org> Bugs item #29186, was opened at 2011-05-08 12:31 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29186&group_id=126 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Greg Hazel (ghazel) Assigned to: Nobody (None) Summary: NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. Initial Comment: Upgraded from 1.7.2 to 1.8.1, got deprecation errors about rubygems itself? NOTE: Gem::SourceIndex#load_gems_in is deprecated with no replacement. It will be removed on or after 2011-11-01. Gem::SourceIndex#load_gems_in called from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:320. 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 /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:127. These make no sense to me, since rubygems seems to be printing deprecation errors about its own code. The later, "NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec." is spammed easily 50 times. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29186&group_id=126 From noreply at rubyforge.org Sun May 8 15:31:59 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 8 May 2011 15:31:59 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29187 ] NOTE: Gem::SourceIndex#initialize is deprecated with no replacement. Message-ID: <20110508193159.4992D1858375@rubyforge.org> Bugs item #29187, was opened at 2011-05-08 12:31 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29187&group_id=126 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Greg Hazel (ghazel) Assigned to: Nobody (None) Summary: NOTE: Gem::SourceIndex#initialize is deprecated with no replacement. Initial Comment: Upgraded from 1.7.2 to 1.8.1, got: NOTE: Gem::SourceIndex#initialize is deprecated with no replacement. It will be removed on or after 2011-11-01. Gem::SourceIndex#initialize called from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/gems/1.8/gems/rails-2.3.11/lib/rails/vendor_gem_source_index.rb:100. "deprecated with no replacement." is not a useful message, since it's not clear how to resolve it. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29187&group_id=126 From noreply at rubyforge.org Sun May 8 15:33:25 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 8 May 2011 15:33:25 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29188 ] rails 2.3.11 fails to load with rubygems 1.8.1 Message-ID: <20110508193325.B13CE1858375@rubyforge.org> Bugs item #29188, was opened at 2011-05-08 12:33 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29188&group_id=126 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Greg Hazel (ghazel) Assigned to: Nobody (None) Summary: rails 2.3.11 fails to load with rubygems 1.8.1 Initial Comment: Upgraded from 1.7.2 to 1.8.1, then a Rails 2.3.11 app failed to load: /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/gems/1.8/gems/rails-2.3.11/lib/rails/gem_dependency.rb:277:in `==': undefined method `name' for "POpen4":String (NoMethodError) from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/site_ruby/1.8/rubygems/dependency.rb:217:in `===' from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/site_ruby/1.8/rubygems/dependency.rb:217:in `matching_specs' from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/site_ruby/1.8/rubygems/specification.rb:539:in `find_all' from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/site_ruby/1.8/rubygems/specification.rb:403:in `each' from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/site_ruby/1.8/rubygems/specification.rb:402:in `each' from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/site_ruby/1.8/rubygems/dependency.rb:216:in `find_all' from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/site_ruby/1.8/rubygems/dependency.rb:216:in `matching_specs' from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/site_ruby/1.8/rubygems/dependency.rb:238:in `to_specs' from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/site_ruby/1.8/rubygems/dependency.rb:256:in `to_spec' from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/site_ruby/1.8/rubygems.rb:1182:in `gem' from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/gems/1.8/gems/rails-2.3.11/lib/rails/gem_dependency.rb:75:in `add_load_paths' from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/gems/1.8/gems/rails-2.3.11/lib/initializer.rb:301:in `add_gem_load_paths' from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/gems/1.8/gems/rails-2.3.11/lib/initializer.rb:301:in `each' from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/gems/1.8/gems/rails-2.3.11/lib/initializer.rb:301:in `add_gem_load_paths' from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/gems/1.8/gems/rails-2.3.11/lib/initializer.rb:132:in `process' from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/gems/1.8/gems/rails-2.3.11/lib/initializer.rb:113:in `send' from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/gems/1.8/gems/rails-2.3.11/lib/initializer.rb:113:in `run' ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29188&group_id=126 From noreply at rubyforge.org Sun May 8 17:38:43 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 8 May 2011 17:38:43 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29187 ] NOTE: Gem::SourceIndex#initialize is deprecated with no replacement. Message-ID: <20110508213843.8556E185838A@rubyforge.org> Bugs item #29187, was opened at 2011-05-08 12:31 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29187&group_id=126 Category: None Group: None >Status: Closed >Resolution: Rejected Priority: 3 Submitted By: Greg Hazel (ghazel) Assigned to: Nobody (None) Summary: NOTE: Gem::SourceIndex#initialize is deprecated with no replacement. Initial Comment: Upgraded from 1.7.2 to 1.8.1, got: NOTE: Gem::SourceIndex#initialize is deprecated with no replacement. It will be removed on or after 2011-11-01. Gem::SourceIndex#initialize called from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/gems/1.8/gems/rails-2.3.11/lib/rails/vendor_gem_source_index.rb:100. "deprecated with no replacement." is not a useful message, since it's not clear how to resolve it. ---------------------------------------------------------------------- >Comment By: Ryan Davis (zenspider) Date: 2011-05-08 14:38 Message: dupe ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29187&group_id=126 From noreply at rubyforge.org Mon May 9 09:22:12 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 9 May 2011 09:22:12 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29190 ] 1.8.1 setup.rb install failure Message-ID: <20110509132212.EF293185838E@rubyforge.org> Bugs item #29190, was opened at 2011-05-09 13:22 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29190&group_id=126 Category: RubyGems installer (setup.rb) Group: next Status: Open Resolution: None Priority: 3 Submitted By: Jon Forums (jonforums) Assigned to: Nobody (None) Summary: 1.8.1 setup.rb install failure Initial Comment: While investigating installing 1.8.1 as the default RG for a RubyInstaller-built Ruby (trunk at 31489) I get the following: ... mkdir -p sandbox/rubygems "C:/projects/rubyinstaller-git/sandbox/extract_utils/basic-bsdtar.exe" -xf "C:/projects/rubyinstaller-git/downloads/rubygems-1.8.1.tgz" > NUL 2>&1 cd sandbox/rubygems ruby setup.rb install --no-ri --no-rdoc C:/projects/rubyinstaller-git/sandbox/rubygems/lib/rubygems/gem_path_searcher.rb:160:in `': uninitialized constant Gem::GemPathSearcher::Deprecate (NameError) from C:/projects/rubyinstaller-git/sandbox/rubygems/lib/rubygems/gem_path_searcher.rb:5:in `' from C:/projects/rubyinstaller-git/sandbox/ruby19_mingw/lib/ruby/1.9.1/rubygems.rb:990:in `searcher' from C:/projects/rubyinstaller-git/sandbox/ruby19_mingw/lib/ruby/1.9.1/rubygems.rb:544:in `find_files' from C:/projects/rubyinstaller-git/sandbox/ruby19_mingw/lib/ruby/1.9.1/rubygems.rb:1165:in `load_plugins' from C:/projects/rubyinstaller-git/sandbox/rubygems/lib/rubygems/gem_runner.rb:85:in `' from C:/projects/rubyinstaller-git/sandbox/ruby19_mingw/lib/ruby/1.9.1/rubygems/custom_require.rb:42:in `require' from C:/projects/rubyinstaller-git/sandbox/ruby19_mingw/lib/ruby/1.9.1/rubygems/custom_require.rb:42:in `require' from setup.rb:25:in `
' I've run out of time this morning to try a few patches for your review, but here's what I speculate: 1) Root cause appears to be a mismatch between Ruby trunk's rubygems.rb and RG's 1.8.1 rubygems.rb. Specifically, Ruby trunk's rubygems.rb does _not_ require 'rubygems/deprecate' as does https://github.com/rubygems/rubygems/blob/master/lib/rubygems.rb#L32 The Quick Wrong Fix of adding the require to gem_path_searcher.rb seems to confirm deprecate.rb is not being required for this scenario. 2) Observed on Win7 32-bit building Ruby trunk with ruby 1.9.2p192. I expect the same failure building ruby_1_8_7, ruby_1_9_2 on Windows or Linux due to the rubygems.rb mismatch. 3) Given (1) should require 'rubygems/deprecate' be refactored somewhere else in the RG code so as not to require a bump in trunk, ruby_1_9_2, and ruby_1_8_7? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29190&group_id=126 From noreply at rubyforge.org Mon May 9 19:54:26 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 9 May 2011 19:54:26 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29191 ] `gem uninstall` complains when the target gem is a development dependency Message-ID: <20110509235426.CBC2F1858363@rubyforge.org> Bugs item #29191, was opened at 2011-05-09 16: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: Open Resolution: None Priority: 3 Submitted By: Aaron Patterson (aaronp) Assigned to: Nobody (None) 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 ~]$ ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29191&group_id=126 From noreply at rubyforge.org Mon May 9 19:57:18 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 9 May 2011 19:57:18 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29191 ] `gem uninstall` complains when the target gem is a development dependency Message-ID: <20110509235718.AC6831858363@rubyforge.org> Bugs item #29191, was opened at 2011-05-09 16: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: Open Resolution: None Priority: 3 Submitted By: Aaron Patterson (aaronp) Assigned to: Nobody (None) 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: Aaron Patterson (aaronp) Date: 2011-05-09 16: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 Mon May 9 19:59:46 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 9 May 2011 19:59:46 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29191 ] `gem uninstall` complains when the target gem is a development dependency Message-ID: <20110509235947.042311858363@rubyforge.org> Bugs item #29191, was opened at 2011-05-09 16: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: Open Resolution: None Priority: 3 Submitted By: Aaron Patterson (aaronp) >Assigned to: Ryan Davis (zenspider) 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: Aaron Patterson (aaronp) Date: 2011-05-09 16: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 16: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 Tue May 10 12:26:14 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 10 May 2011 12:26:14 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29176 ] Scary warnings are scaring helpless developers who can't do a thing about it Message-ID: <20110510162614.45DA8185837F@rubyforge.org> Bugs item #29176, was opened at 2011-05-06 16: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: Scott Tadman (tadman) Date: 2011-05-10 12: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 14: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 12: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 04:56 Message: No worries. ---------------------------------------------------------------------- Comment By: Justin Collins (presidentbeef) Date: 2011-05-08 02:57 Message: Sorry, my mistake. I didn't notice that gem was called out specifically. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-05-08 02: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-08 02: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-08 02: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-08 01: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 18: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 17: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 16: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 16: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 16: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 May 10 13:55:54 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 10 May 2011 13:55:54 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29176 ] Scary warnings are scaring helpless developers who can't do a thing about it Message-ID: <20110510175554.D2DAA18583AB@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-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 May 10 17:42:07 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 10 May 2011 17:42:07 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29196 ] Upgrading from 1.6.1 via `gem update --system` breaks Message-ID: <20110510214210.3C03D18583AF@rubyforge.org> Bugs item #29196, was opened at 2011-05-10 14:42 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29196&group_id=126 Category: `gem` commands (other) Group: None Status: Open Resolution: None Priority: 3 Submitted By: Aaron Patterson (aaronp) Assigned to: Nobody (None) Summary: Upgrading from 1.6.1 via `gem update --system` breaks Initial Comment: [aaron at mobile-166-187-123-124 ~]$ ruby -v ruby 1.9.3dev (2011-05-09 trunk 31496) [x86_64-darwin10.7.0] [aaron at mobile-166-187-123-124 ~]$ gem update --system Updating rubygems-update Successfully installed rubygems-update-1.8.1 Installing RubyGems 1.8.1 /Users/aaron/.local/lib/ruby/gems/1.9.1/gems/rubygems-update-1.8.1/lib/rubygems/gem_path_searcher.rb:160:in `': uninitialized constant Gem::GemPathSearcher::Deprecate (NameError) from /Users/aaron/.local/lib/ruby/gems/1.9.1/gems/rubygems-update-1.8.1/lib/rubygems/gem_path_searcher.rb:5:in `' from /Users/aaron/.local/lib/ruby/site_ruby/1.9.1/rubygems.rb:983:in `searcher' from /Users/aaron/.local/lib/ruby/site_ruby/1.9.1/rubygems.rb:537:in `find_files' from /Users/aaron/.local/lib/ruby/site_ruby/1.9.1/rubygems.rb:1158:in `load_plugins' from /Users/aaron/.local/lib/ruby/gems/1.9.1/gems/rubygems-update-1.8.1/lib/rubygems/gem_runner.rb:85:in `' from /Users/aaron/.local/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:36:in `require' from /Users/aaron/.local/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:36:in `require' from setup.rb:25:in `
' [aaron at mobile-166-187-123-124 ~]$ gem env RubyGems Environment: - RUBYGEMS VERSION: 1.6.1 - RUBY VERSION: 1.9.3 (2011-05-09 patchlevel -1) [x86_64-darwin10.7.0] - INSTALLATION DIRECTORY: /Users/aaron/.local/lib/ruby/gems/1.9.1 - RUBY EXECUTABLE: /Users/aaron/.local/bin/ruby - EXECUTABLE DIRECTORY: /Users/aaron/.local/bin - RUBYGEMS PLATFORMS: - ruby - x86_64-darwin-10 - GEM PATHS: - /Users/aaron/.local/lib/ruby/gems/1.9.1 - /Users/aaron/.gem/ruby/1.9.1 - GEM CONFIGURATION: - :update_sources => true - :verbose => true - :benchmark => false - :backtrace => false - :bulk_threshold => 1000 - "install" => "--format-executable --no-user-install" - "gemcutter_key" => "********************************" - :sources => ["http://gems.rubyforge.org/"] - "update" => "--format-executable --no-user-install" - REMOTE SOURCES: - http://gems.rubyforge.org/ [aaron at mobile-166-187-123-124 ~]$ ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29196&group_id=126 From noreply at rubyforge.org Tue May 10 19:56:52 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 10 May 2011 19:56:52 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29198 ] gem rdoc uses some deprecated methods Message-ID: <20110510235652.DC76918583B2@rubyforge.org> Bugs item #29198, was opened at 2011-05-10 23: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: Nobody (None) 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! ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29198&group_id=126 From noreply at rubyforge.org Tue May 10 21:36:16 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 10 May 2011 21:36:16 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29176 ] Scary warnings are scaring helpless developers who can't do a thing about it Message-ID: <20110511013616.7128818583A7@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: 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 May 10 22:05:01 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 10 May 2011 22:05:01 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29196 ] Upgrading from 1.6.1 via `gem update --system` breaks Message-ID: <20110511020502.01F1518583A9@rubyforge.org> Bugs item #29196, was opened at 2011-05-10 14:42 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29196&group_id=126 Category: `gem` commands (other) Group: None Status: Open Resolution: None Priority: 3 Submitted By: Aaron Patterson (aaronp) Assigned to: Nobody (None) Summary: Upgrading from 1.6.1 via `gem update --system` breaks Initial Comment: [aaron at mobile-166-187-123-124 ~]$ ruby -v ruby 1.9.3dev (2011-05-09 trunk 31496) [x86_64-darwin10.7.0] [aaron at mobile-166-187-123-124 ~]$ gem update --system Updating rubygems-update Successfully installed rubygems-update-1.8.1 Installing RubyGems 1.8.1 /Users/aaron/.local/lib/ruby/gems/1.9.1/gems/rubygems-update-1.8.1/lib/rubygems/gem_path_searcher.rb:160:in `': uninitialized constant Gem::GemPathSearcher::Deprecate (NameError) from /Users/aaron/.local/lib/ruby/gems/1.9.1/gems/rubygems-update-1.8.1/lib/rubygems/gem_path_searcher.rb:5:in `' from /Users/aaron/.local/lib/ruby/site_ruby/1.9.1/rubygems.rb:983:in `searcher' from /Users/aaron/.local/lib/ruby/site_ruby/1.9.1/rubygems.rb:537:in `find_files' from /Users/aaron/.local/lib/ruby/site_ruby/1.9.1/rubygems.rb:1158:in `load_plugins' from /Users/aaron/.local/lib/ruby/gems/1.9.1/gems/rubygems-update-1.8.1/lib/rubygems/gem_runner.rb:85:in `' from /Users/aaron/.local/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:36:in `require' from /Users/aaron/.local/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:36:in `require' from setup.rb:25:in `
' [aaron at mobile-166-187-123-124 ~]$ gem env RubyGems Environment: - RUBYGEMS VERSION: 1.6.1 - RUBY VERSION: 1.9.3 (2011-05-09 patchlevel -1) [x86_64-darwin10.7.0] - INSTALLATION DIRECTORY: /Users/aaron/.local/lib/ruby/gems/1.9.1 - RUBY EXECUTABLE: /Users/aaron/.local/bin/ruby - EXECUTABLE DIRECTORY: /Users/aaron/.local/bin - RUBYGEMS PLATFORMS: - ruby - x86_64-darwin-10 - GEM PATHS: - /Users/aaron/.local/lib/ruby/gems/1.9.1 - /Users/aaron/.gem/ruby/1.9.1 - GEM CONFIGURATION: - :update_sources => true - :verbose => true - :benchmark => false - :backtrace => false - :bulk_threshold => 1000 - "install" => "--format-executable --no-user-install" - "gemcutter_key" => "********************************" - :sources => ["http://gems.rubyforge.org/"] - "update" => "--format-executable --no-user-install" - REMOTE SOURCES: - http://gems.rubyforge.org/ [aaron at mobile-166-187-123-124 ~]$ ---------------------------------------------------------------------- Comment By: Steve Loveless (turboladen) Date: 2011-05-10 19:05 Message: While I'm not seeing the same error, I too can't upgrade from 1.6.2 or 1.7.2 to 1.8.0/1. I've tried 3 times now: 1. MRI 1.9.2, rubygems 1.7.2. ** Did `gem update --system` then `gem pristine --all --no-extensions` 2. MRI 1.9.2, rubygems 1.6.2 ** Did `gem update --system` then `gem pristine --all --no-extensions` 3. MRI 1.9.2, rubygems 1.6.2 ** Did `gem install rubygems-update && update_rubygems` By doing the 1st 2, I can no longer use any `gem` commands; even just `gem` results in a backtrace (see more [here]{http://stackoverflow.com/questions/5932984/how-do-i-get-gem-working-again-after-upgrading-to-rubygems-1-8-x} With the 3rd command, the upgrade just fails (with the same backtrace as the first 2) but I'm left with a usable install, just still on rubygems 1.6.2. Here's the backtrace: /Users/sloveless/.rvm/gems/ruby-1.9.2-p180/gems/rubygems-update-1.8.1/lib/rubygems/specification.rb:277:in `block in _resort!': undefined method `name' for nil:NilClass (NoMethodError) from /Users/sloveless/.rvm/gems/ruby-1.9.2-p180/gems/rubygems-update-1.8.1/lib/rubygems/specification.rb:276:in `sort!' from /Users/sloveless/.rvm/gems/ruby-1.9.2-p180/gems/rubygems-update-1.8.1/lib/rubygems/specification.rb:276:in `_resort!' from /Users/sloveless/.rvm/gems/ruby-1.9.2-p180/gems/rubygems-update-1.8.1/lib/rubygems/specification.rb:270:in `_all' from /Users/sloveless/.rvm/gems/ruby-1.9.2-p180/gems/rubygems-update-1.8.1/lib/rubygems/specification.rb:402:in `each' from /Users/sloveless/.rvm/gems/ruby-1.9.2-p180/gems/rubygems-update-1.8.1/lib/rubygems.rb:477:in `map' from /Users/sloveless/.rvm/gems/ruby-1.9.2-p180/gems/rubygems-update-1.8.1/lib/rubygems.rb:477:in `find_files' from /Users/sloveless/.rvm/gems/ruby-1.9.2-p180/gems/rubygems-update-1.8.1/lib/rubygems.rb:1061:in `load_plugins' from /Users/sloveless/.rvm/gems/ruby-1.9.2-p180/gems/rubygems-update-1.8.1/lib/rubygems/gem_runner.rb:85:in `' from /Users/sloveless/.rvm/gems/ruby-1.9.2-p180/gems/rubygems-update-1.8.1/lib/rubygems/custom_require.rb:36:in `require' from /Users/sloveless/.rvm/gems/ruby-1.9.2-p180/gems/rubygems-update-1.8.1/lib/rubygems/custom_require.rb:36:in `require' from setup.rb:25:in `
' And... [sloveless at sloveless-mbp:pelco]$ gem env [/Users/sloveless/.rvm/gems/ruby-1.9.2-p180/specifications/ssh_command_runner-3.0.0.gemspec] isn't a Gem::Specification (NilClass instead). RubyGems Environment: - RUBYGEMS VERSION: 1.6.2 - RUBY VERSION: 1.9.2 (2011-02-18 patchlevel 180) [x86_64-darwin10.7.0] - INSTALLATION DIRECTORY: /Users/sloveless/.rvm/gems/ruby-1.9.2-p180 - RUBY EXECUTABLE: /Users/sloveless/.rvm/rubies/ruby-1.9.2-p180/bin/ruby - EXECUTABLE DIRECTORY: /Users/sloveless/.rvm/gems/ruby-1.9.2-p180/bin - RUBYGEMS PLATFORMS: - ruby - x86_64-darwin-10 - GEM PATHS: - /Users/sloveless/.rvm/gems/ruby-1.9.2-p180 - /Users/sloveless/.rvm/gems/ruby-1.9.2-p180 at global - GEM CONFIGURATION: - :update_sources => true - :verbose => true - :benchmark => false - :backtrace => false - :bulk_threshold => 1000 - :sources => ["http://rubygems.org"] - REMOTE SOURCES: - http://rubygems.org ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29196&group_id=126 From noreply at rubyforge.org Tue May 10 23:13:19 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 10 May 2011 23:13:19 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29176 ] Scary warnings are scaring helpless developers who can't do a thing about it Message-ID: <20110511031319.3D6D41858372@rubyforge.org> Bugs item #29176, was opened at 2011-05-06 15: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: Stephen Bannasch (stepheneb) Date: 2011-05-10 22: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 20: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 12: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 11: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 13: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 11: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 03:56 Message: No worries. ---------------------------------------------------------------------- Comment By: Justin Collins (presidentbeef) Date: 2011-05-08 01:57 Message: Sorry, my mistake. I didn't notice that gem was called out specifically. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-05-08 01: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-08 01: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-08 01: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-08 00: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 17: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 16: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 15: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 15: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 15: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 Wed May 11 00:37:33 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 11 May 2011 00:37:33 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29176 ] Scary warnings are scaring helpless developers who can't do a thing about it Message-ID: <20110511043734.761ED1858372@rubyforge.org> Bugs item #29176, was opened at 2011-05-06 16: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: Scott Tadman (tadman) Date: 2011-05-11 00: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 23: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 21: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 13: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 12: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 14: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 12: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 04:56 Message: No worries. ---------------------------------------------------------------------- Comment By: Justin Collins (presidentbeef) Date: 2011-05-08 02:57 Message: Sorry, my mistake. I didn't notice that gem was called out specifically. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-05-08 02: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-08 02: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-08 02: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-08 01: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 18: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 17: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 16: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 16: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 16: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 Wed May 11 05:02:22 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 11 May 2011 05:02:22 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29176 ] Scary warnings are scaring helpless developers who can't do a thing about it Message-ID: <20110511090222.518FB18583A7@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-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 Wed May 11 05:02:45 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 11 May 2011 05:02:45 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29198 ] gem rdoc uses some deprecated methods Message-ID: <20110511090246.031BC18583A9@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! ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29198&group_id=126 From noreply at rubyforge.org Wed May 11 09:56:48 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 11 May 2011 09:56:48 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29196 ] Upgrading from 1.6.1 via `gem update --system` breaks Message-ID: <20110511135648.D9940185838A@rubyforge.org> Bugs item #29196, was opened at 2011-05-10 21:42 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29196&group_id=126 Category: `gem` commands (other) Group: None Status: Open Resolution: None Priority: 3 Submitted By: Aaron Patterson (aaronp) Assigned to: Nobody (None) Summary: Upgrading from 1.6.1 via `gem update --system` breaks Initial Comment: [aaron at mobile-166-187-123-124 ~]$ ruby -v ruby 1.9.3dev (2011-05-09 trunk 31496) [x86_64-darwin10.7.0] [aaron at mobile-166-187-123-124 ~]$ gem update --system Updating rubygems-update Successfully installed rubygems-update-1.8.1 Installing RubyGems 1.8.1 /Users/aaron/.local/lib/ruby/gems/1.9.1/gems/rubygems-update-1.8.1/lib/rubygems/gem_path_searcher.rb:160:in `': uninitialized constant Gem::GemPathSearcher::Deprecate (NameError) from /Users/aaron/.local/lib/ruby/gems/1.9.1/gems/rubygems-update-1.8.1/lib/rubygems/gem_path_searcher.rb:5:in `' from /Users/aaron/.local/lib/ruby/site_ruby/1.9.1/rubygems.rb:983:in `searcher' from /Users/aaron/.local/lib/ruby/site_ruby/1.9.1/rubygems.rb:537:in `find_files' from /Users/aaron/.local/lib/ruby/site_ruby/1.9.1/rubygems.rb:1158:in `load_plugins' from /Users/aaron/.local/lib/ruby/gems/1.9.1/gems/rubygems-update-1.8.1/lib/rubygems/gem_runner.rb:85:in `' from /Users/aaron/.local/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:36:in `require' from /Users/aaron/.local/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:36:in `require' from setup.rb:25:in `
' [aaron at mobile-166-187-123-124 ~]$ gem env RubyGems Environment: - RUBYGEMS VERSION: 1.6.1 - RUBY VERSION: 1.9.3 (2011-05-09 patchlevel -1) [x86_64-darwin10.7.0] - INSTALLATION DIRECTORY: /Users/aaron/.local/lib/ruby/gems/1.9.1 - RUBY EXECUTABLE: /Users/aaron/.local/bin/ruby - EXECUTABLE DIRECTORY: /Users/aaron/.local/bin - RUBYGEMS PLATFORMS: - ruby - x86_64-darwin-10 - GEM PATHS: - /Users/aaron/.local/lib/ruby/gems/1.9.1 - /Users/aaron/.gem/ruby/1.9.1 - GEM CONFIGURATION: - :update_sources => true - :verbose => true - :benchmark => false - :backtrace => false - :bulk_threshold => 1000 - "install" => "--format-executable --no-user-install" - "gemcutter_key" => "********************************" - :sources => ["http://gems.rubyforge.org/"] - "update" => "--format-executable --no-user-install" - REMOTE SOURCES: - http://gems.rubyforge.org/ [aaron at mobile-166-187-123-124 ~]$ ---------------------------------------------------------------------- Comment By: Jon Forums (jonforums) Date: 2011-05-11 13:56 Message: Aaron, do you think this is caused by the same root cause I suspect in [#29190], namely mismatched rubygems.rb wrt require 'rubygems/deprecate' ---------------------------------------------------------------------- Comment By: Steve Loveless (turboladen) Date: 2011-05-11 02:05 Message: While I'm not seeing the same error, I too can't upgrade from 1.6.2 or 1.7.2 to 1.8.0/1. I've tried 3 times now: 1. MRI 1.9.2, rubygems 1.7.2. ** Did `gem update --system` then `gem pristine --all --no-extensions` 2. MRI 1.9.2, rubygems 1.6.2 ** Did `gem update --system` then `gem pristine --all --no-extensions` 3. MRI 1.9.2, rubygems 1.6.2 ** Did `gem install rubygems-update && update_rubygems` By doing the 1st 2, I can no longer use any `gem` commands; even just `gem` results in a backtrace (see more [here]{http://stackoverflow.com/questions/5932984/how-do-i-get-gem-working-again-after-upgrading-to-rubygems-1-8-x} With the 3rd command, the upgrade just fails (with the same backtrace as the first 2) but I'm left with a usable install, just still on rubygems 1.6.2. Here's the backtrace: /Users/sloveless/.rvm/gems/ruby-1.9.2-p180/gems/rubygems-update-1.8.1/lib/rubygems/specification.rb:277:in `block in _resort!': undefined method `name' for nil:NilClass (NoMethodError) from /Users/sloveless/.rvm/gems/ruby-1.9.2-p180/gems/rubygems-update-1.8.1/lib/rubygems/specification.rb:276:in `sort!' from /Users/sloveless/.rvm/gems/ruby-1.9.2-p180/gems/rubygems-update-1.8.1/lib/rubygems/specification.rb:276:in `_resort!' from /Users/sloveless/.rvm/gems/ruby-1.9.2-p180/gems/rubygems-update-1.8.1/lib/rubygems/specification.rb:270:in `_all' from /Users/sloveless/.rvm/gems/ruby-1.9.2-p180/gems/rubygems-update-1.8.1/lib/rubygems/specification.rb:402:in `each' from /Users/sloveless/.rvm/gems/ruby-1.9.2-p180/gems/rubygems-update-1.8.1/lib/rubygems.rb:477:in `map' from /Users/sloveless/.rvm/gems/ruby-1.9.2-p180/gems/rubygems-update-1.8.1/lib/rubygems.rb:477:in `find_files' from /Users/sloveless/.rvm/gems/ruby-1.9.2-p180/gems/rubygems-update-1.8.1/lib/rubygems.rb:1061:in `load_plugins' from /Users/sloveless/.rvm/gems/ruby-1.9.2-p180/gems/rubygems-update-1.8.1/lib/rubygems/gem_runner.rb:85:in `' from /Users/sloveless/.rvm/gems/ruby-1.9.2-p180/gems/rubygems-update-1.8.1/lib/rubygems/custom_require.rb:36:in `require' from /Users/sloveless/.rvm/gems/ruby-1.9.2-p180/gems/rubygems-update-1.8.1/lib/rubygems/custom_require.rb:36:in `require' from setup.rb:25:in `
' And... [sloveless at sloveless-mbp:pelco]$ gem env [/Users/sloveless/.rvm/gems/ruby-1.9.2-p180/specifications/ssh_command_runner-3.0.0.gemspec] isn't a Gem::Specification (NilClass instead). RubyGems Environment: - RUBYGEMS VERSION: 1.6.2 - RUBY VERSION: 1.9.2 (2011-02-18 patchlevel 180) [x86_64-darwin10.7.0] - INSTALLATION DIRECTORY: /Users/sloveless/.rvm/gems/ruby-1.9.2-p180 - RUBY EXECUTABLE: /Users/sloveless/.rvm/rubies/ruby-1.9.2-p180/bin/ruby - EXECUTABLE DIRECTORY: /Users/sloveless/.rvm/gems/ruby-1.9.2-p180/bin - RUBYGEMS PLATFORMS: - ruby - x86_64-darwin-10 - GEM PATHS: - /Users/sloveless/.rvm/gems/ruby-1.9.2-p180 - /Users/sloveless/.rvm/gems/ruby-1.9.2-p180 at global - GEM CONFIGURATION: - :update_sources => true - :verbose => true - :benchmark => false - :backtrace => false - :bulk_threshold => 1000 - :sources => ["http://rubygems.org"] - REMOTE SOURCES: - http://rubygems.org ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29196&group_id=126 From noreply at rubyforge.org Wed May 11 14:06:37 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 11 May 2011 14:06:37 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29176 ] Scary warnings are scaring helpless developers who can't do a thing about it Message-ID: <20110511180637.B770118583A6@rubyforge.org> Bugs item #29176, was opened at 2011-05-06 16: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: Scott Tadman (tadman) Date: 2011-05-11 14: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 05: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-11 00: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 23: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 21: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 13: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 12: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 14: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 12: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 04:56 Message: No worries. ---------------------------------------------------------------------- Comment By: Justin Collins (presidentbeef) Date: 2011-05-08 02:57 Message: Sorry, my mistake. I didn't notice that gem was called out specifically. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-05-08 02: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-08 02: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-08 02: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-08 01: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 18: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 17: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 16: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 16: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 16: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 Wed May 11 18:18:30 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 11 May 2011 18:18:30 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29196 ] Upgrading from 1.6.1 via `gem update --system` breaks Message-ID: <20110511221830.C7E1815B8029@rubyforge.org> Bugs item #29196, was opened at 2011-05-10 14:42 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29196&group_id=126 Category: `gem` commands (other) Group: None Status: Open Resolution: None Priority: 3 Submitted By: Aaron Patterson (aaronp) Assigned to: Nobody (None) Summary: Upgrading from 1.6.1 via `gem update --system` breaks Initial Comment: [aaron at mobile-166-187-123-124 ~]$ ruby -v ruby 1.9.3dev (2011-05-09 trunk 31496) [x86_64-darwin10.7.0] [aaron at mobile-166-187-123-124 ~]$ gem update --system Updating rubygems-update Successfully installed rubygems-update-1.8.1 Installing RubyGems 1.8.1 /Users/aaron/.local/lib/ruby/gems/1.9.1/gems/rubygems-update-1.8.1/lib/rubygems/gem_path_searcher.rb:160:in `': uninitialized constant Gem::GemPathSearcher::Deprecate (NameError) from /Users/aaron/.local/lib/ruby/gems/1.9.1/gems/rubygems-update-1.8.1/lib/rubygems/gem_path_searcher.rb:5:in `' from /Users/aaron/.local/lib/ruby/site_ruby/1.9.1/rubygems.rb:983:in `searcher' from /Users/aaron/.local/lib/ruby/site_ruby/1.9.1/rubygems.rb:537:in `find_files' from /Users/aaron/.local/lib/ruby/site_ruby/1.9.1/rubygems.rb:1158:in `load_plugins' from /Users/aaron/.local/lib/ruby/gems/1.9.1/gems/rubygems-update-1.8.1/lib/rubygems/gem_runner.rb:85:in `' from /Users/aaron/.local/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:36:in `require' from /Users/aaron/.local/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:36:in `require' from setup.rb:25:in `
' [aaron at mobile-166-187-123-124 ~]$ gem env RubyGems Environment: - RUBYGEMS VERSION: 1.6.1 - RUBY VERSION: 1.9.3 (2011-05-09 patchlevel -1) [x86_64-darwin10.7.0] - INSTALLATION DIRECTORY: /Users/aaron/.local/lib/ruby/gems/1.9.1 - RUBY EXECUTABLE: /Users/aaron/.local/bin/ruby - EXECUTABLE DIRECTORY: /Users/aaron/.local/bin - RUBYGEMS PLATFORMS: - ruby - x86_64-darwin-10 - GEM PATHS: - /Users/aaron/.local/lib/ruby/gems/1.9.1 - /Users/aaron/.gem/ruby/1.9.1 - GEM CONFIGURATION: - :update_sources => true - :verbose => true - :benchmark => false - :backtrace => false - :bulk_threshold => 1000 - "install" => "--format-executable --no-user-install" - "gemcutter_key" => "********************************" - :sources => ["http://gems.rubyforge.org/"] - "update" => "--format-executable --no-user-install" - REMOTE SOURCES: - http://gems.rubyforge.org/ [aaron at mobile-166-187-123-124 ~]$ ---------------------------------------------------------------------- >Comment By: Ryan Davis (zenspider) Date: 2011-05-11 15:18 Message: Aaron... I can't repro at all. ---------------------------------------------------------------------- Comment By: Jon Forums (jonforums) Date: 2011-05-11 06:56 Message: Aaron, do you think this is caused by the same root cause I suspect in [#29190], namely mismatched rubygems.rb wrt require 'rubygems/deprecate' ---------------------------------------------------------------------- Comment By: Steve Loveless (turboladen) Date: 2011-05-10 19:05 Message: While I'm not seeing the same error, I too can't upgrade from 1.6.2 or 1.7.2 to 1.8.0/1. I've tried 3 times now: 1. MRI 1.9.2, rubygems 1.7.2. ** Did `gem update --system` then `gem pristine --all --no-extensions` 2. MRI 1.9.2, rubygems 1.6.2 ** Did `gem update --system` then `gem pristine --all --no-extensions` 3. MRI 1.9.2, rubygems 1.6.2 ** Did `gem install rubygems-update && update_rubygems` By doing the 1st 2, I can no longer use any `gem` commands; even just `gem` results in a backtrace (see more [here]{http://stackoverflow.com/questions/5932984/how-do-i-get-gem-working-again-after-upgrading-to-rubygems-1-8-x} With the 3rd command, the upgrade just fails (with the same backtrace as the first 2) but I'm left with a usable install, just still on rubygems 1.6.2. Here's the backtrace: /Users/sloveless/.rvm/gems/ruby-1.9.2-p180/gems/rubygems-update-1.8.1/lib/rubygems/specification.rb:277:in `block in _resort!': undefined method `name' for nil:NilClass (NoMethodError) from /Users/sloveless/.rvm/gems/ruby-1.9.2-p180/gems/rubygems-update-1.8.1/lib/rubygems/specification.rb:276:in `sort!' from /Users/sloveless/.rvm/gems/ruby-1.9.2-p180/gems/rubygems-update-1.8.1/lib/rubygems/specification.rb:276:in `_resort!' from /Users/sloveless/.rvm/gems/ruby-1.9.2-p180/gems/rubygems-update-1.8.1/lib/rubygems/specification.rb:270:in `_all' from /Users/sloveless/.rvm/gems/ruby-1.9.2-p180/gems/rubygems-update-1.8.1/lib/rubygems/specification.rb:402:in `each' from /Users/sloveless/.rvm/gems/ruby-1.9.2-p180/gems/rubygems-update-1.8.1/lib/rubygems.rb:477:in `map' from /Users/sloveless/.rvm/gems/ruby-1.9.2-p180/gems/rubygems-update-1.8.1/lib/rubygems.rb:477:in `find_files' from /Users/sloveless/.rvm/gems/ruby-1.9.2-p180/gems/rubygems-update-1.8.1/lib/rubygems.rb:1061:in `load_plugins' from /Users/sloveless/.rvm/gems/ruby-1.9.2-p180/gems/rubygems-update-1.8.1/lib/rubygems/gem_runner.rb:85:in `' from /Users/sloveless/.rvm/gems/ruby-1.9.2-p180/gems/rubygems-update-1.8.1/lib/rubygems/custom_require.rb:36:in `require' from /Users/sloveless/.rvm/gems/ruby-1.9.2-p180/gems/rubygems-update-1.8.1/lib/rubygems/custom_require.rb:36:in `require' from setup.rb:25:in `
' And... [sloveless at sloveless-mbp:pelco]$ gem env [/Users/sloveless/.rvm/gems/ruby-1.9.2-p180/specifications/ssh_command_runner-3.0.0.gemspec] isn't a Gem::Specification (NilClass instead). RubyGems Environment: - RUBYGEMS VERSION: 1.6.2 - RUBY VERSION: 1.9.2 (2011-02-18 patchlevel 180) [x86_64-darwin10.7.0] - INSTALLATION DIRECTORY: /Users/sloveless/.rvm/gems/ruby-1.9.2-p180 - RUBY EXECUTABLE: /Users/sloveless/.rvm/rubies/ruby-1.9.2-p180/bin/ruby - EXECUTABLE DIRECTORY: /Users/sloveless/.rvm/gems/ruby-1.9.2-p180/bin - RUBYGEMS PLATFORMS: - ruby - x86_64-darwin-10 - GEM PATHS: - /Users/sloveless/.rvm/gems/ruby-1.9.2-p180 - /Users/sloveless/.rvm/gems/ruby-1.9.2-p180 at global - GEM CONFIGURATION: - :update_sources => true - :verbose => true - :benchmark => false - :backtrace => false - :bulk_threshold => 1000 - :sources => ["http://rubygems.org"] - REMOTE SOURCES: - http://rubygems.org ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29196&group_id=126 From noreply at rubyforge.org Wed May 11 18:42:57 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 11 May 2011 18:42:57 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29196 ] Upgrading from 1.6.1 via `gem update --system` breaks Message-ID: <20110511224257.CB5631858376@rubyforge.org> Bugs item #29196, was opened at 2011-05-10 14:42 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29196&group_id=126 Category: `gem` commands (other) Group: None Status: Open Resolution: None Priority: 3 Submitted By: Aaron Patterson (aaronp) Assigned to: Nobody (None) Summary: Upgrading from 1.6.1 via `gem update --system` breaks Initial Comment: [aaron at mobile-166-187-123-124 ~]$ ruby -v ruby 1.9.3dev (2011-05-09 trunk 31496) [x86_64-darwin10.7.0] [aaron at mobile-166-187-123-124 ~]$ gem update --system Updating rubygems-update Successfully installed rubygems-update-1.8.1 Installing RubyGems 1.8.1 /Users/aaron/.local/lib/ruby/gems/1.9.1/gems/rubygems-update-1.8.1/lib/rubygems/gem_path_searcher.rb:160:in `': uninitialized constant Gem::GemPathSearcher::Deprecate (NameError) from /Users/aaron/.local/lib/ruby/gems/1.9.1/gems/rubygems-update-1.8.1/lib/rubygems/gem_path_searcher.rb:5:in `' from /Users/aaron/.local/lib/ruby/site_ruby/1.9.1/rubygems.rb:983:in `searcher' from /Users/aaron/.local/lib/ruby/site_ruby/1.9.1/rubygems.rb:537:in `find_files' from /Users/aaron/.local/lib/ruby/site_ruby/1.9.1/rubygems.rb:1158:in `load_plugins' from /Users/aaron/.local/lib/ruby/gems/1.9.1/gems/rubygems-update-1.8.1/lib/rubygems/gem_runner.rb:85:in `' from /Users/aaron/.local/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:36:in `require' from /Users/aaron/.local/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:36:in `require' from setup.rb:25:in `
' [aaron at mobile-166-187-123-124 ~]$ gem env RubyGems Environment: - RUBYGEMS VERSION: 1.6.1 - RUBY VERSION: 1.9.3 (2011-05-09 patchlevel -1) [x86_64-darwin10.7.0] - INSTALLATION DIRECTORY: /Users/aaron/.local/lib/ruby/gems/1.9.1 - RUBY EXECUTABLE: /Users/aaron/.local/bin/ruby - EXECUTABLE DIRECTORY: /Users/aaron/.local/bin - RUBYGEMS PLATFORMS: - ruby - x86_64-darwin-10 - GEM PATHS: - /Users/aaron/.local/lib/ruby/gems/1.9.1 - /Users/aaron/.gem/ruby/1.9.1 - GEM CONFIGURATION: - :update_sources => true - :verbose => true - :benchmark => false - :backtrace => false - :bulk_threshold => 1000 - "install" => "--format-executable --no-user-install" - "gemcutter_key" => "********************************" - :sources => ["http://gems.rubyforge.org/"] - "update" => "--format-executable --no-user-install" - REMOTE SOURCES: - http://gems.rubyforge.org/ [aaron at mobile-166-187-123-124 ~]$ ---------------------------------------------------------------------- >Comment By: Aaron Patterson (aaronp) Date: 2011-05-11 15:42 Message: I did this on a fresh install of 1.9.3dev: 504 ruby -v 505 cd ~/Downloads/ 506 ls -tr 507 tar zxvf rubygems-1.6.1.tgz 508 cd rubygems-1.6.1 509 ls 510 ruby setup.rb 511 gem -v 512 gem update --system 513 history | tail ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-05-11 15:18 Message: Aaron... I can't repro at all. ---------------------------------------------------------------------- Comment By: Jon Forums (jonforums) Date: 2011-05-11 06:56 Message: Aaron, do you think this is caused by the same root cause I suspect in [#29190], namely mismatched rubygems.rb wrt require 'rubygems/deprecate' ---------------------------------------------------------------------- Comment By: Steve Loveless (turboladen) Date: 2011-05-10 19:05 Message: While I'm not seeing the same error, I too can't upgrade from 1.6.2 or 1.7.2 to 1.8.0/1. I've tried 3 times now: 1. MRI 1.9.2, rubygems 1.7.2. ** Did `gem update --system` then `gem pristine --all --no-extensions` 2. MRI 1.9.2, rubygems 1.6.2 ** Did `gem update --system` then `gem pristine --all --no-extensions` 3. MRI 1.9.2, rubygems 1.6.2 ** Did `gem install rubygems-update && update_rubygems` By doing the 1st 2, I can no longer use any `gem` commands; even just `gem` results in a backtrace (see more [here]{http://stackoverflow.com/questions/5932984/how-do-i-get-gem-working-again-after-upgrading-to-rubygems-1-8-x} With the 3rd command, the upgrade just fails (with the same backtrace as the first 2) but I'm left with a usable install, just still on rubygems 1.6.2. Here's the backtrace: /Users/sloveless/.rvm/gems/ruby-1.9.2-p180/gems/rubygems-update-1.8.1/lib/rubygems/specification.rb:277:in `block in _resort!': undefined method `name' for nil:NilClass (NoMethodError) from /Users/sloveless/.rvm/gems/ruby-1.9.2-p180/gems/rubygems-update-1.8.1/lib/rubygems/specification.rb:276:in `sort!' from /Users/sloveless/.rvm/gems/ruby-1.9.2-p180/gems/rubygems-update-1.8.1/lib/rubygems/specification.rb:276:in `_resort!' from /Users/sloveless/.rvm/gems/ruby-1.9.2-p180/gems/rubygems-update-1.8.1/lib/rubygems/specification.rb:270:in `_all' from /Users/sloveless/.rvm/gems/ruby-1.9.2-p180/gems/rubygems-update-1.8.1/lib/rubygems/specification.rb:402:in `each' from /Users/sloveless/.rvm/gems/ruby-1.9.2-p180/gems/rubygems-update-1.8.1/lib/rubygems.rb:477:in `map' from /Users/sloveless/.rvm/gems/ruby-1.9.2-p180/gems/rubygems-update-1.8.1/lib/rubygems.rb:477:in `find_files' from /Users/sloveless/.rvm/gems/ruby-1.9.2-p180/gems/rubygems-update-1.8.1/lib/rubygems.rb:1061:in `load_plugins' from /Users/sloveless/.rvm/gems/ruby-1.9.2-p180/gems/rubygems-update-1.8.1/lib/rubygems/gem_runner.rb:85:in `' from /Users/sloveless/.rvm/gems/ruby-1.9.2-p180/gems/rubygems-update-1.8.1/lib/rubygems/custom_require.rb:36:in `require' from /Users/sloveless/.rvm/gems/ruby-1.9.2-p180/gems/rubygems-update-1.8.1/lib/rubygems/custom_require.rb:36:in `require' from setup.rb:25:in `
' And... [sloveless at sloveless-mbp:pelco]$ gem env [/Users/sloveless/.rvm/gems/ruby-1.9.2-p180/specifications/ssh_command_runner-3.0.0.gemspec] isn't a Gem::Specification (NilClass instead). RubyGems Environment: - RUBYGEMS VERSION: 1.6.2 - RUBY VERSION: 1.9.2 (2011-02-18 patchlevel 180) [x86_64-darwin10.7.0] - INSTALLATION DIRECTORY: /Users/sloveless/.rvm/gems/ruby-1.9.2-p180 - RUBY EXECUTABLE: /Users/sloveless/.rvm/rubies/ruby-1.9.2-p180/bin/ruby - EXECUTABLE DIRECTORY: /Users/sloveless/.rvm/gems/ruby-1.9.2-p180/bin - RUBYGEMS PLATFORMS: - ruby - x86_64-darwin-10 - GEM PATHS: - /Users/sloveless/.rvm/gems/ruby-1.9.2-p180 - /Users/sloveless/.rvm/gems/ruby-1.9.2-p180 at global - GEM CONFIGURATION: - :update_sources => true - :verbose => true - :benchmark => false - :backtrace => false - :bulk_threshold => 1000 - :sources => ["http://rubygems.org"] - REMOTE SOURCES: - http://rubygems.org ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29196&group_id=126 From noreply at rubyforge.org Wed May 11 18:50:38 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 11 May 2011 18:50:38 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29196 ] Upgrading from 1.6.1 via `gem update --system` breaks Message-ID: <20110511225042.28F1B18583A8@rubyforge.org> Bugs item #29196, was opened at 2011-05-10 14:42 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29196&group_id=126 Category: `gem` commands (other) Group: None Status: Open Resolution: None Priority: 3 Submitted By: Aaron Patterson (aaronp) Assigned to: Nobody (None) Summary: Upgrading from 1.6.1 via `gem update --system` breaks Initial Comment: [aaron at mobile-166-187-123-124 ~]$ ruby -v ruby 1.9.3dev (2011-05-09 trunk 31496) [x86_64-darwin10.7.0] [aaron at mobile-166-187-123-124 ~]$ gem update --system Updating rubygems-update Successfully installed rubygems-update-1.8.1 Installing RubyGems 1.8.1 /Users/aaron/.local/lib/ruby/gems/1.9.1/gems/rubygems-update-1.8.1/lib/rubygems/gem_path_searcher.rb:160:in `': uninitialized constant Gem::GemPathSearcher::Deprecate (NameError) from /Users/aaron/.local/lib/ruby/gems/1.9.1/gems/rubygems-update-1.8.1/lib/rubygems/gem_path_searcher.rb:5:in `' from /Users/aaron/.local/lib/ruby/site_ruby/1.9.1/rubygems.rb:983:in `searcher' from /Users/aaron/.local/lib/ruby/site_ruby/1.9.1/rubygems.rb:537:in `find_files' from /Users/aaron/.local/lib/ruby/site_ruby/1.9.1/rubygems.rb:1158:in `load_plugins' from /Users/aaron/.local/lib/ruby/gems/1.9.1/gems/rubygems-update-1.8.1/lib/rubygems/gem_runner.rb:85:in `' from /Users/aaron/.local/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:36:in `require' from /Users/aaron/.local/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:36:in `require' from setup.rb:25:in `
' [aaron at mobile-166-187-123-124 ~]$ gem env RubyGems Environment: - RUBYGEMS VERSION: 1.6.1 - RUBY VERSION: 1.9.3 (2011-05-09 patchlevel -1) [x86_64-darwin10.7.0] - INSTALLATION DIRECTORY: /Users/aaron/.local/lib/ruby/gems/1.9.1 - RUBY EXECUTABLE: /Users/aaron/.local/bin/ruby - EXECUTABLE DIRECTORY: /Users/aaron/.local/bin - RUBYGEMS PLATFORMS: - ruby - x86_64-darwin-10 - GEM PATHS: - /Users/aaron/.local/lib/ruby/gems/1.9.1 - /Users/aaron/.gem/ruby/1.9.1 - GEM CONFIGURATION: - :update_sources => true - :verbose => true - :benchmark => false - :backtrace => false - :bulk_threshold => 1000 - "install" => "--format-executable --no-user-install" - "gemcutter_key" => "********************************" - :sources => ["http://gems.rubyforge.org/"] - "update" => "--format-executable --no-user-install" - REMOTE SOURCES: - http://gems.rubyforge.org/ [aaron at mobile-166-187-123-124 ~]$ ---------------------------------------------------------------------- >Comment By: Aaron Patterson (aaronp) Date: 2011-05-11 15:50 Message: Just to update: I suck. Just trying to upgrade to rubygems 1.8.1 with a clean install of 1.9.3dev will break. No need to install anything else. ---------------------------------------------------------------------- Comment By: Aaron Patterson (aaronp) Date: 2011-05-11 15:42 Message: I did this on a fresh install of 1.9.3dev: 504 ruby -v 505 cd ~/Downloads/ 506 ls -tr 507 tar zxvf rubygems-1.6.1.tgz 508 cd rubygems-1.6.1 509 ls 510 ruby setup.rb 511 gem -v 512 gem update --system 513 history | tail ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-05-11 15:18 Message: Aaron... I can't repro at all. ---------------------------------------------------------------------- Comment By: Jon Forums (jonforums) Date: 2011-05-11 06:56 Message: Aaron, do you think this is caused by the same root cause I suspect in [#29190], namely mismatched rubygems.rb wrt require 'rubygems/deprecate' ---------------------------------------------------------------------- Comment By: Steve Loveless (turboladen) Date: 2011-05-10 19:05 Message: While I'm not seeing the same error, I too can't upgrade from 1.6.2 or 1.7.2 to 1.8.0/1. I've tried 3 times now: 1. MRI 1.9.2, rubygems 1.7.2. ** Did `gem update --system` then `gem pristine --all --no-extensions` 2. MRI 1.9.2, rubygems 1.6.2 ** Did `gem update --system` then `gem pristine --all --no-extensions` 3. MRI 1.9.2, rubygems 1.6.2 ** Did `gem install rubygems-update && update_rubygems` By doing the 1st 2, I can no longer use any `gem` commands; even just `gem` results in a backtrace (see more [here]{http://stackoverflow.com/questions/5932984/how-do-i-get-gem-working-again-after-upgrading-to-rubygems-1-8-x} With the 3rd command, the upgrade just fails (with the same backtrace as the first 2) but I'm left with a usable install, just still on rubygems 1.6.2. Here's the backtrace: /Users/sloveless/.rvm/gems/ruby-1.9.2-p180/gems/rubygems-update-1.8.1/lib/rubygems/specification.rb:277:in `block in _resort!': undefined method `name' for nil:NilClass (NoMethodError) from /Users/sloveless/.rvm/gems/ruby-1.9.2-p180/gems/rubygems-update-1.8.1/lib/rubygems/specification.rb:276:in `sort!' from /Users/sloveless/.rvm/gems/ruby-1.9.2-p180/gems/rubygems-update-1.8.1/lib/rubygems/specification.rb:276:in `_resort!' from /Users/sloveless/.rvm/gems/ruby-1.9.2-p180/gems/rubygems-update-1.8.1/lib/rubygems/specification.rb:270:in `_all' from /Users/sloveless/.rvm/gems/ruby-1.9.2-p180/gems/rubygems-update-1.8.1/lib/rubygems/specification.rb:402:in `each' from /Users/sloveless/.rvm/gems/ruby-1.9.2-p180/gems/rubygems-update-1.8.1/lib/rubygems.rb:477:in `map' from /Users/sloveless/.rvm/gems/ruby-1.9.2-p180/gems/rubygems-update-1.8.1/lib/rubygems.rb:477:in `find_files' from /Users/sloveless/.rvm/gems/ruby-1.9.2-p180/gems/rubygems-update-1.8.1/lib/rubygems.rb:1061:in `load_plugins' from /Users/sloveless/.rvm/gems/ruby-1.9.2-p180/gems/rubygems-update-1.8.1/lib/rubygems/gem_runner.rb:85:in `' from /Users/sloveless/.rvm/gems/ruby-1.9.2-p180/gems/rubygems-update-1.8.1/lib/rubygems/custom_require.rb:36:in `require' from /Users/sloveless/.rvm/gems/ruby-1.9.2-p180/gems/rubygems-update-1.8.1/lib/rubygems/custom_require.rb:36:in `require' from setup.rb:25:in `
' And... [sloveless at sloveless-mbp:pelco]$ gem env [/Users/sloveless/.rvm/gems/ruby-1.9.2-p180/specifications/ssh_command_runner-3.0.0.gemspec] isn't a Gem::Specification (NilClass instead). RubyGems Environment: - RUBYGEMS VERSION: 1.6.2 - RUBY VERSION: 1.9.2 (2011-02-18 patchlevel 180) [x86_64-darwin10.7.0] - INSTALLATION DIRECTORY: /Users/sloveless/.rvm/gems/ruby-1.9.2-p180 - RUBY EXECUTABLE: /Users/sloveless/.rvm/rubies/ruby-1.9.2-p180/bin/ruby - EXECUTABLE DIRECTORY: /Users/sloveless/.rvm/gems/ruby-1.9.2-p180/bin - RUBYGEMS PLATFORMS: - ruby - x86_64-darwin-10 - GEM PATHS: - /Users/sloveless/.rvm/gems/ruby-1.9.2-p180 - /Users/sloveless/.rvm/gems/ruby-1.9.2-p180 at global - GEM CONFIGURATION: - :update_sources => true - :verbose => true - :benchmark => false - :backtrace => false - :bulk_threshold => 1000 - :sources => ["http://rubygems.org"] - REMOTE SOURCES: - http://rubygems.org ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29196&group_id=126 From noreply at rubyforge.org Wed May 11 19:25:35 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 11 May 2011 19:25:35 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29176 ] Scary warnings are scaring helpless developers who can't do a thing about it Message-ID: <20110511232535.CA8B815B8029@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-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 Wed May 11 20:49:08 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 11 May 2011 20:49:08 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29196 ] Upgrading from 1.6.1 via `gem update --system` breaks Message-ID: <20110512004909.0D3691858376@rubyforge.org> Bugs item #29196, was opened at 2011-05-10 14:42 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29196&group_id=126 Category: `gem` commands (other) Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Aaron Patterson (aaronp) >Assigned to: Ryan Davis (zenspider) Summary: Upgrading from 1.6.1 via `gem update --system` breaks Initial Comment: [aaron at mobile-166-187-123-124 ~]$ ruby -v ruby 1.9.3dev (2011-05-09 trunk 31496) [x86_64-darwin10.7.0] [aaron at mobile-166-187-123-124 ~]$ gem update --system Updating rubygems-update Successfully installed rubygems-update-1.8.1 Installing RubyGems 1.8.1 /Users/aaron/.local/lib/ruby/gems/1.9.1/gems/rubygems-update-1.8.1/lib/rubygems/gem_path_searcher.rb:160:in `': uninitialized constant Gem::GemPathSearcher::Deprecate (NameError) from /Users/aaron/.local/lib/ruby/gems/1.9.1/gems/rubygems-update-1.8.1/lib/rubygems/gem_path_searcher.rb:5:in `' from /Users/aaron/.local/lib/ruby/site_ruby/1.9.1/rubygems.rb:983:in `searcher' from /Users/aaron/.local/lib/ruby/site_ruby/1.9.1/rubygems.rb:537:in `find_files' from /Users/aaron/.local/lib/ruby/site_ruby/1.9.1/rubygems.rb:1158:in `load_plugins' from /Users/aaron/.local/lib/ruby/gems/1.9.1/gems/rubygems-update-1.8.1/lib/rubygems/gem_runner.rb:85:in `' from /Users/aaron/.local/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:36:in `require' from /Users/aaron/.local/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:36:in `require' from setup.rb:25:in `
' [aaron at mobile-166-187-123-124 ~]$ gem env RubyGems Environment: - RUBYGEMS VERSION: 1.6.1 - RUBY VERSION: 1.9.3 (2011-05-09 patchlevel -1) [x86_64-darwin10.7.0] - INSTALLATION DIRECTORY: /Users/aaron/.local/lib/ruby/gems/1.9.1 - RUBY EXECUTABLE: /Users/aaron/.local/bin/ruby - EXECUTABLE DIRECTORY: /Users/aaron/.local/bin - RUBYGEMS PLATFORMS: - ruby - x86_64-darwin-10 - GEM PATHS: - /Users/aaron/.local/lib/ruby/gems/1.9.1 - /Users/aaron/.gem/ruby/1.9.1 - GEM CONFIGURATION: - :update_sources => true - :verbose => true - :benchmark => false - :backtrace => false - :bulk_threshold => 1000 - "install" => "--format-executable --no-user-install" - "gemcutter_key" => "********************************" - :sources => ["http://gems.rubyforge.org/"] - "update" => "--format-executable --no-user-install" - REMOTE SOURCES: - http://gems.rubyforge.org/ [aaron at mobile-166-187-123-124 ~]$ ---------------------------------------------------------------------- >Comment By: Ryan Davis (zenspider) Date: 2011-05-11 17:49 Message: Repro'd and done. ---------------------------------------------------------------------- Comment By: Aaron Patterson (aaronp) Date: 2011-05-11 15:50 Message: Just to update: I suck. Just trying to upgrade to rubygems 1.8.1 with a clean install of 1.9.3dev will break. No need to install anything else. ---------------------------------------------------------------------- Comment By: Aaron Patterson (aaronp) Date: 2011-05-11 15:42 Message: I did this on a fresh install of 1.9.3dev: 504 ruby -v 505 cd ~/Downloads/ 506 ls -tr 507 tar zxvf rubygems-1.6.1.tgz 508 cd rubygems-1.6.1 509 ls 510 ruby setup.rb 511 gem -v 512 gem update --system 513 history | tail ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-05-11 15:18 Message: Aaron... I can't repro at all. ---------------------------------------------------------------------- Comment By: Jon Forums (jonforums) Date: 2011-05-11 06:56 Message: Aaron, do you think this is caused by the same root cause I suspect in [#29190], namely mismatched rubygems.rb wrt require 'rubygems/deprecate' ---------------------------------------------------------------------- Comment By: Steve Loveless (turboladen) Date: 2011-05-10 19:05 Message: While I'm not seeing the same error, I too can't upgrade from 1.6.2 or 1.7.2 to 1.8.0/1. I've tried 3 times now: 1. MRI 1.9.2, rubygems 1.7.2. ** Did `gem update --system` then `gem pristine --all --no-extensions` 2. MRI 1.9.2, rubygems 1.6.2 ** Did `gem update --system` then `gem pristine --all --no-extensions` 3. MRI 1.9.2, rubygems 1.6.2 ** Did `gem install rubygems-update && update_rubygems` By doing the 1st 2, I can no longer use any `gem` commands; even just `gem` results in a backtrace (see more [here]{http://stackoverflow.com/questions/5932984/how-do-i-get-gem-working-again-after-upgrading-to-rubygems-1-8-x} With the 3rd command, the upgrade just fails (with the same backtrace as the first 2) but I'm left with a usable install, just still on rubygems 1.6.2. Here's the backtrace: /Users/sloveless/.rvm/gems/ruby-1.9.2-p180/gems/rubygems-update-1.8.1/lib/rubygems/specification.rb:277:in `block in _resort!': undefined method `name' for nil:NilClass (NoMethodError) from /Users/sloveless/.rvm/gems/ruby-1.9.2-p180/gems/rubygems-update-1.8.1/lib/rubygems/specification.rb:276:in `sort!' from /Users/sloveless/.rvm/gems/ruby-1.9.2-p180/gems/rubygems-update-1.8.1/lib/rubygems/specification.rb:276:in `_resort!' from /Users/sloveless/.rvm/gems/ruby-1.9.2-p180/gems/rubygems-update-1.8.1/lib/rubygems/specification.rb:270:in `_all' from /Users/sloveless/.rvm/gems/ruby-1.9.2-p180/gems/rubygems-update-1.8.1/lib/rubygems/specification.rb:402:in `each' from /Users/sloveless/.rvm/gems/ruby-1.9.2-p180/gems/rubygems-update-1.8.1/lib/rubygems.rb:477:in `map' from /Users/sloveless/.rvm/gems/ruby-1.9.2-p180/gems/rubygems-update-1.8.1/lib/rubygems.rb:477:in `find_files' from /Users/sloveless/.rvm/gems/ruby-1.9.2-p180/gems/rubygems-update-1.8.1/lib/rubygems.rb:1061:in `load_plugins' from /Users/sloveless/.rvm/gems/ruby-1.9.2-p180/gems/rubygems-update-1.8.1/lib/rubygems/gem_runner.rb:85:in `' from /Users/sloveless/.rvm/gems/ruby-1.9.2-p180/gems/rubygems-update-1.8.1/lib/rubygems/custom_require.rb:36:in `require' from /Users/sloveless/.rvm/gems/ruby-1.9.2-p180/gems/rubygems-update-1.8.1/lib/rubygems/custom_require.rb:36:in `require' from setup.rb:25:in `
' And... [sloveless at sloveless-mbp:pelco]$ gem env [/Users/sloveless/.rvm/gems/ruby-1.9.2-p180/specifications/ssh_command_runner-3.0.0.gemspec] isn't a Gem::Specification (NilClass instead). RubyGems Environment: - RUBYGEMS VERSION: 1.6.2 - RUBY VERSION: 1.9.2 (2011-02-18 patchlevel 180) [x86_64-darwin10.7.0] - INSTALLATION DIRECTORY: /Users/sloveless/.rvm/gems/ruby-1.9.2-p180 - RUBY EXECUTABLE: /Users/sloveless/.rvm/rubies/ruby-1.9.2-p180/bin/ruby - EXECUTABLE DIRECTORY: /Users/sloveless/.rvm/gems/ruby-1.9.2-p180/bin - RUBYGEMS PLATFORMS: - ruby - x86_64-darwin-10 - GEM PATHS: - /Users/sloveless/.rvm/gems/ruby-1.9.2-p180 - /Users/sloveless/.rvm/gems/ruby-1.9.2-p180 at global - GEM CONFIGURATION: - :update_sources => true - :verbose => true - :benchmark => false - :backtrace => false - :bulk_threshold => 1000 - :sources => ["http://rubygems.org"] - REMOTE SOURCES: - http://rubygems.org ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29196&group_id=126 From noreply at rubyforge.org Wed May 11 20:51:19 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 11 May 2011 20:51:19 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29190 ] 1.8.1 setup.rb install failure Message-ID: <20110512005119.E54881858376@rubyforge.org> Bugs item #29190, was opened at 2011-05-09 06:22 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29190&group_id=126 Category: RubyGems installer (setup.rb) Group: next >Status: Closed >Resolution: Rejected Priority: 3 Submitted By: Jon Forums (jonforums) Assigned to: Nobody (None) Summary: 1.8.1 setup.rb install failure Initial Comment: While investigating installing 1.8.1 as the default RG for a RubyInstaller-built Ruby (trunk at 31489) I get the following: ... mkdir -p sandbox/rubygems "C:/projects/rubyinstaller-git/sandbox/extract_utils/basic-bsdtar.exe" -xf "C:/projects/rubyinstaller-git/downloads/rubygems-1.8.1.tgz" > NUL 2>&1 cd sandbox/rubygems ruby setup.rb install --no-ri --no-rdoc C:/projects/rubyinstaller-git/sandbox/rubygems/lib/rubygems/gem_path_searcher.rb:160:in `': uninitialized constant Gem::GemPathSearcher::Deprecate (NameError) from C:/projects/rubyinstaller-git/sandbox/rubygems/lib/rubygems/gem_path_searcher.rb:5:in `' from C:/projects/rubyinstaller-git/sandbox/ruby19_mingw/lib/ruby/1.9.1/rubygems.rb:990:in `searcher' from C:/projects/rubyinstaller-git/sandbox/ruby19_mingw/lib/ruby/1.9.1/rubygems.rb:544:in `find_files' from C:/projects/rubyinstaller-git/sandbox/ruby19_mingw/lib/ruby/1.9.1/rubygems.rb:1165:in `load_plugins' from C:/projects/rubyinstaller-git/sandbox/rubygems/lib/rubygems/gem_runner.rb:85:in `' from C:/projects/rubyinstaller-git/sandbox/ruby19_mingw/lib/ruby/1.9.1/rubygems/custom_require.rb:42:in `require' from C:/projects/rubyinstaller-git/sandbox/ruby19_mingw/lib/ruby/1.9.1/rubygems/custom_require.rb:42:in `require' from setup.rb:25:in `
' I've run out of time this morning to try a few patches for your review, but here's what I speculate: 1) Root cause appears to be a mismatch between Ruby trunk's rubygems.rb and RG's 1.8.1 rubygems.rb. Specifically, Ruby trunk's rubygems.rb does _not_ require 'rubygems/deprecate' as does https://github.com/rubygems/rubygems/blob/master/lib/rubygems.rb#L32 The Quick Wrong Fix of adding the require to gem_path_searcher.rb seems to confirm deprecate.rb is not being required for this scenario. 2) Observed on Win7 32-bit building Ruby trunk with ruby 1.9.2p192. I expect the same failure building ruby_1_8_7, ruby_1_9_2 on Windows or Linux due to the rubygems.rb mismatch. 3) Given (1) should require 'rubygems/deprecate' be refactored somewhere else in the RG code so as not to require a bump in trunk, ruby_1_9_2, and ruby_1_8_7? ---------------------------------------------------------------------- >Comment By: Ryan Davis (zenspider) Date: 2011-05-11 17:51 Message: tenderlove gave me proper repro steps so this is a dupe. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29190&group_id=126 From drbrain at segment7.net Wed May 11 20:54:00 2011 From: drbrain at segment7.net (Eric Hodel) Date: Wed, 11 May 2011 17:54:00 -0700 Subject: [Rubygems-developers] [ANN] rubygems-update 1.8.2 Released Message-ID: <25DC92FC-5231-4963-A055-B4A57C97403F@segment7.net> rubygems-update version 1.8.2 has been released! * * * * * RubyGems is a package management framework for Ruby. This gem is an update for the RubyGems software. You must have an installation of RubyGems before this update can be applied. See Gem for information on RubyGems (or `ri Gem`) To upgrade to the latest RubyGems, run: $ gem update --system # you might need to be an administrator or root See UPGRADING.rdoc for more details and alternative instructions. ----- If you don't have RubyGems installed, your can still do it manually: * Download from: https://rubygems.org/pages/download * Unpack into a directory and cd there * Install with: ruby setup.rb # you may need admin/root privilege For more details and other options, see: ruby setup.rb --help Changes: === 1.8.2 / 2011-05-11 After installing RubyGems 1.8 or newer you will see deprecations when loading your exsting gems. Run `gem pristine --all --no-extensions` to regenerate your gem specifications safely. Currently RubyGems does not save the build arguments used to build gems with extensions. You will need to run `gem pristine gem_with_extension -- --build-arg` to regenerate a gem with an extension where it requires special build arguments. * 2 minor enhancements: * Moved #outdated from OutdatedCommand to Specification (for Isolate). * Print out a warning about missing executables. * 3 bug fixes: * Added missing requires to fix various upgrade issues. * `gem pristine` respects multiple gem repositories. * setup.rb now execs with --disable-gems when possible From noreply at rubyforge.org Wed May 11 23:22:32 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 11 May 2011 23:22:32 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29186 ] NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. Message-ID: <20110512032232.E81BE18583A9@rubyforge.org> Bugs item #29186, was opened at 2011-05-08 12:31 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29186&group_id=126 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Greg Hazel (ghazel) Assigned to: Nobody (None) Summary: NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. Initial Comment: Upgraded from 1.7.2 to 1.8.1, got deprecation errors about rubygems itself? NOTE: Gem::SourceIndex#load_gems_in is deprecated with no replacement. It will be removed on or after 2011-11-01. Gem::SourceIndex#load_gems_in called from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:320. 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 /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:127. These make no sense to me, since rubygems seems to be printing deprecation errors about its own code. The later, "NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec." is spammed easily 50 times. ---------------------------------------------------------------------- Comment By: Alex Chaffee (alexch) Date: 2011-05-11 20:22 Message: I installed my patched version of RubyGems (see bug #29176) to get a better report and it looks like he's right: RubyGems 1.8 is complaining about its own code. Here's the list of 9 places where source_index.rb calls deprecated methods. pepper:rubygems [ruby-1.9.2-p0] alex$ gem rdoc bundler Error loading RubyGems plugin "/Users/alex/.rvm/gems/ruby-1.9.2-p0/gems/yard-0.6.4/lib/rubygems_plugin.rb": undefined method `overwrite_accessor' for Gem::Specification:Class (NoMethodError) Warning: Gem::SourceIndex.from_installed_gems is deprecated with no replacement It will be removed on or after 2011-10-01. (Further warnings suppressed until exit.) called from /Users/alex/.rvm/rubies/ruby-1.9.2-p0/lib/ruby/site_ruby/1.9.1/rubygems/commands/rdoc_command.rb:64 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. Gem::SourceIndex#add_spec is deprecated; use Specification.add_spec instead. It will be removed on or after 2011-11-01. called from /Users/alex/.rvm/rubies/ruby-1.9.2-p0/lib/ruby/site_ruby/1.9.1/rubygems/source_index.rb:127 Gem::SourceIndex#initialize is deprecated with no replacement It will be removed on or after 2011-11-01. called from /Users/alex/.rvm/rubies/ruby-1.9.2-p0/lib/ruby/site_ruby/1.9.1/rubygems/source_index.rb:67 Gem::SourceIndex#load_gems_in is deprecated with no replacement It will be removed on or after 2011-11-01. called from /Users/alex/.rvm/rubies/ruby-1.9.2-p0/lib/ruby/site_ruby/1.9.1/rubygems/source_index.rb:320 Gem::SourceIndex#refresh! is deprecated with no replacement It will be removed on or after 2011-11-01. called from /Users/alex/.rvm/rubies/ruby-1.9.2-p0/lib/ruby/site_ruby/1.9.1/rubygems/source_index.rb:95 Gem::SourceIndex#search is deprecated with no replacement It will be removed on or after 2011-11-01. called from /Users/alex/.rvm/rubies/ruby-1.9.2-p0/lib/ruby/site_ruby/1.9.1/rubygems/commands/rdoc_command.rb:64 Gem::SourceIndex#spec_dirs= is deprecated; use Specification.dirs= instead. It will be removed on or after 2011-11-01. called from /Users/alex/.rvm/rubies/ruby-1.9.2-p0/lib/ruby/site_ruby/1.9.1/rubygems/source_index.rb:94 Gem::SourceIndex.from_gems_in is deprecated with no replacement It will be removed on or after 2011-10-01. called from /Users/alex/.rvm/rubies/ruby-1.9.2-p0/lib/ruby/site_ruby/1.9.1/rubygems/source_index.rb:47 Gem::SourceIndex.from_installed_gems is deprecated with no replacement It will be removed on or after 2011-10-01. called from /Users/alex/.rvm/rubies/ruby-1.9.2-p0/lib/ruby/site_ruby/1.9.1/rubygems/commands/rdoc_command.rb:64 Gem::SourceIndex.installed_spec_directories is deprecated; use Specification.dirs instead. It will be removed on or after 2011-11-01. called from /Users/alex/.rvm/rubies/ruby-1.9.2-p0/lib/ruby/site_ruby/1.9.1/rubygems/source_index.rb:47 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29186&group_id=126 From noreply at rubyforge.org Wed May 11 23:32:59 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 11 May 2011 23:32:59 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29188 ] rails 2.3.11 fails to load with rubygems 1.8.1 Message-ID: <20110512033259.E3D4B18583A9@rubyforge.org> Bugs item #29188, was opened at 2011-05-08 12:33 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29188&group_id=126 >Category: other Group: None Status: Open >Resolution: Rejected Priority: 3 Submitted By: Greg Hazel (ghazel) >Assigned to: Ryan Davis (zenspider) Summary: rails 2.3.11 fails to load with rubygems 1.8.1 Initial Comment: Upgraded from 1.7.2 to 1.8.1, then a Rails 2.3.11 app failed to load: /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/gems/1.8/gems/rails-2.3.11/lib/rails/gem_dependency.rb:277:in `==': undefined method `name' for "POpen4":String (NoMethodError) from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/site_ruby/1.8/rubygems/dependency.rb:217:in `===' from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/site_ruby/1.8/rubygems/dependency.rb:217:in `matching_specs' from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/site_ruby/1.8/rubygems/specification.rb:539:in `find_all' from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/site_ruby/1.8/rubygems/specification.rb:403:in `each' from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/site_ruby/1.8/rubygems/specification.rb:402:in `each' from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/site_ruby/1.8/rubygems/dependency.rb:216:in `find_all' from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/site_ruby/1.8/rubygems/dependency.rb:216:in `matching_specs' from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/site_ruby/1.8/rubygems/dependency.rb:238:in `to_specs' from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/site_ruby/1.8/rubygems/dependency.rb:256:in `to_spec' from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/site_ruby/1.8/rubygems.rb:1182:in `gem' from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/gems/1.8/gems/rails-2.3.11/lib/rails/gem_dependency.rb:75:in `add_load_paths' from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/gems/1.8/gems/rails-2.3.11/lib/initializer.rb:301:in `add_gem_load_paths' from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/gems/1.8/gems/rails-2.3.11/lib/initializer.rb:301:in `each' from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/gems/1.8/gems/rails-2.3.11/lib/initializer.rb:301:in `add_gem_load_paths' from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/gems/1.8/gems/rails-2.3.11/lib/initializer.rb:132:in `process' from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/gems/1.8/gems/rails-2.3.11/lib/initializer.rb:113:in `send' from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/gems/1.8/gems/rails-2.3.11/lib/initializer.rb:113:in `run' ---------------------------------------------------------------------- >Comment By: Ryan Davis (zenspider) Date: 2011-05-11 20:32 Message: Cleaned up path that works in my rubygems checkout: rails-2.3.11/lib/rails/gem_dependency.rb:277:in `==': undefined method `name' for "POpen4":String (NoMethodError) from lib/rubygems/dependency.rb:217:in `===' from lib/rubygems/dependency.rb:217:in `matching_specs' from lib/rubygems/specification.rb:539:in `find_all' from lib/rubygems/specification.rb:403:in `each' from lib/rubygems/specification.rb:402:in `each' from lib/rubygems/dependency.rb:216:in `find_all' from lib/rubygems/dependency.rb:216:in `matching_specs' from lib/rubygems/dependency.rb:238:in `to_specs' from lib/rubygems/dependency.rb:256:in `to_spec' from lib/rubygems.rb:1182:in `gem' from rails-2.3.11/lib/rails/gem_dependency.rb:75:in `add_load_paths' from rails-2.3.11/lib/initializer.rb:301:in `add_gem_load_paths' from rails-2.3.11/lib/initializer.rb:301:in `each' from rails-2.3.11/lib/initializer.rb:301:in `add_gem_load_paths' from rails-2.3.11/lib/initializer.rb:132:in `process' from rails-2.3.11/lib/initializer.rb:113:in `send' from rails-2.3.11/lib/initializer.rb:113:in `run' gem_dependency.rb:277 is a buggy impl of #==: def ==(other) self.name == other.name && self.requirement == other.requirement end It's simply bad form to not check the class first. Not sure how that ever passed code review. That alone would probably fix the issue, but I'm not sure as I can't tell you why their call of #name returns another dep. Couple that with a very sketchy implementation: def add_load_paths self.class.add_frozen_gem_path return if @loaded || @load_paths_added if framework_gem? @load_paths_added = @loaded = @frozen = true return end gem self @spec = Gem.loaded_specs[name] @frozen = @spec.loaded_from.include?(self.class.unpacked_path) if @spec @load_paths_added = true rescue Gem::LoadError end `gem self` where self is a GemDependency (a subclass of our Gem::Dependency) just doesn't make sense. I'm not sure how this ever worked and it is possible it never did given that completely blithe rescue at the bottom... ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29188&group_id=126 From noreply at rubyforge.org Wed May 11 23:50:47 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 11 May 2011 23:50:47 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29185 ] NOTE: Gem::SourceIndex#refresh! is deprecated with no replacement. Message-ID: <20110512035047.484701858361@rubyforge.org> Bugs item #29185, was opened at 2011-05-08 12:29 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29185&group_id=126 >Category: you broke my monkeypatch! Group: None >Status: Closed >Resolution: Rejected Priority: 3 Submitted By: Greg Hazel (ghazel) >Assigned to: Ryan Davis (zenspider) Summary: NOTE: Gem::SourceIndex#refresh! is deprecated with no replacement. Initial Comment: Upgraded from 1.7.2 to 1.8.1, got: NOTE: Gem::SourceIndex#refresh! is deprecated with no replacement. It will be removed on or after 2011-11-01. Gem::SourceIndex#refresh! called from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/gems/1.8/gems/rails-2.3.11/lib/rails/vendor_gem_source_index.rb:34. "deprecated with no replacement" is not a useful message, since it's not clear how to resolve it. ---------------------------------------------------------------------- >Comment By: Ryan Davis (zenspider) Date: 2011-05-11 20:50 Message: It is clear how to resolve it: rails-2.3.11/lib/rails/vendor_gem_source_index.rb calls deprecated code. If it doesn't, then the deprecation goes away. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29185&group_id=126 From noreply at rubyforge.org Wed May 11 23:51:51 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 11 May 2011 23:51:51 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29184 ] NOTE: Gem::Specification#default_executable= is deprecated with no replacement. Message-ID: <20110512035151.54EDA15B8029@rubyforge.org> Bugs item #29184, was opened at 2011-05-08 12:27 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29184&group_id=126 >Category: you broke my monkeypatch! Group: None >Status: Closed >Resolution: Rejected Priority: 3 Submitted By: Greg Hazel (ghazel) >Assigned to: Ryan Davis (zenspider) Summary: NOTE: Gem::Specification#default_executable= is deprecated with no replacement. Initial Comment: Upgraded from 1.7.2 to 1.8.1 and got lots of messages like: Gem::Specification#default_executable= called from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/gems/1.8/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. "With no replacement" is not a very useful message, since it's not clear how to resolve this. Also, tons of gems cause this warning, so maybe the deprecation is not such a great idea. ---------------------------------------------------------------------- >Comment By: Ryan Davis (zenspider) Date: 2011-05-11 20:51 Message: dupe: repeating the exact same ticket multiple times does nothing. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29184&group_id=126 From noreply at rubyforge.org Wed May 11 23:52:07 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 11 May 2011 23:52:07 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29185 ] NOTE: Gem::SourceIndex#refresh! is deprecated with no replacement. Message-ID: <20110512035207.ACB001858361@rubyforge.org> Bugs item #29185, was opened at 2011-05-08 12:29 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29185&group_id=126 Category: you broke my monkeypatch! Group: None Status: Closed Resolution: Rejected Priority: 3 Submitted By: Greg Hazel (ghazel) Assigned to: Ryan Davis (zenspider) Summary: NOTE: Gem::SourceIndex#refresh! is deprecated with no replacement. Initial Comment: Upgraded from 1.7.2 to 1.8.1, got: NOTE: Gem::SourceIndex#refresh! is deprecated with no replacement. It will be removed on or after 2011-11-01. Gem::SourceIndex#refresh! called from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/gems/1.8/gems/rails-2.3.11/lib/rails/vendor_gem_source_index.rb:34. "deprecated with no replacement" is not a useful message, since it's not clear how to resolve it. ---------------------------------------------------------------------- Comment By: Greg Hazel (ghazel) Date: 2011-05-11 20:52 Message: But what about the functionality of that call? ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-05-11 20:50 Message: It is clear how to resolve it: rails-2.3.11/lib/rails/vendor_gem_source_index.rb calls deprecated code. If it doesn't, then the deprecation goes away. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29185&group_id=126 From noreply at rubyforge.org Wed May 11 23:52:58 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 11 May 2011 23:52:58 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29184 ] NOTE: Gem::Specification#default_executable= is deprecated with no replacement. Message-ID: <20110512035258.591521858361@rubyforge.org> Bugs item #29184, was opened at 2011-05-08 12:27 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29184&group_id=126 Category: you broke my monkeypatch! Group: None Status: Closed Resolution: Rejected Priority: 3 Submitted By: Greg Hazel (ghazel) Assigned to: Ryan Davis (zenspider) Summary: NOTE: Gem::Specification#default_executable= is deprecated with no replacement. Initial Comment: Upgraded from 1.7.2 to 1.8.1 and got lots of messages like: Gem::Specification#default_executable= called from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/gems/1.8/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. "With no replacement" is not a very useful message, since it's not clear how to resolve this. Also, tons of gems cause this warning, so maybe the deprecation is not such a great idea. ---------------------------------------------------------------------- >Comment By: Greg Hazel (ghazel) Date: 2011-05-11 20:52 Message: I had not filed a ticket about "Gem::Specification#default_executable=" before. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-05-11 20:51 Message: dupe: repeating the exact same ticket multiple times does nothing. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29184&group_id=126 From noreply at rubyforge.org Wed May 11 23:53:05 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 11 May 2011 23:53:05 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29186 ] NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. Message-ID: <20110512035305.54B3A1858361@rubyforge.org> Bugs item #29186, was opened at 2011-05-08 12:31 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29186&group_id=126 >Category: you broke my monkeypatch! Group: None >Status: Closed >Resolution: Rejected Priority: 3 Submitted By: Greg Hazel (ghazel) >Assigned to: Ryan Davis (zenspider) Summary: NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. Initial Comment: Upgraded from 1.7.2 to 1.8.1, got deprecation errors about rubygems itself? NOTE: Gem::SourceIndex#load_gems_in is deprecated with no replacement. It will be removed on or after 2011-11-01. Gem::SourceIndex#load_gems_in called from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:320. 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 /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:127. These make no sense to me, since rubygems seems to be printing deprecation errors about its own code. The later, "NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec." is spammed easily 50 times. ---------------------------------------------------------------------- >Comment By: Ryan Davis (zenspider) Date: 2011-05-11 20:53 Message: dupe. you're being a jackass both here and in IRC. ---------------------------------------------------------------------- Comment By: Alex Chaffee (alexch) Date: 2011-05-11 20:22 Message: I installed my patched version of RubyGems (see bug #29176) to get a better report and it looks like he's right: RubyGems 1.8 is complaining about its own code. Here's the list of 9 places where source_index.rb calls deprecated methods. pepper:rubygems [ruby-1.9.2-p0] alex$ gem rdoc bundler Error loading RubyGems plugin "/Users/alex/.rvm/gems/ruby-1.9.2-p0/gems/yard-0.6.4/lib/rubygems_plugin.rb": undefined method `overwrite_accessor' for Gem::Specification:Class (NoMethodError) Warning: Gem::SourceIndex.from_installed_gems is deprecated with no replacement It will be removed on or after 2011-10-01. (Further warnings suppressed until exit.) called from /Users/alex/.rvm/rubies/ruby-1.9.2-p0/lib/ruby/site_ruby/1.9.1/rubygems/commands/rdoc_command.rb:64 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. Gem::SourceIndex#add_spec is deprecated; use Specification.add_spec instead. It will be removed on or after 2011-11-01. called from /Users/alex/.rvm/rubies/ruby-1.9.2-p0/lib/ruby/site_ruby/1.9.1/rubygems/source_index.rb:127 Gem::SourceIndex#initialize is deprecated with no replacement It will be removed on or after 2011-11-01. called from /Users/alex/.rvm/rubies/ruby-1.9.2-p0/lib/ruby/site_ruby/1.9.1/rubygems/source_index.rb:67 Gem::SourceIndex#load_gems_in is deprecated with no replacement It will be removed on or after 2011-11-01. called from /Users/alex/.rvm/rubies/ruby-1.9.2-p0/lib/ruby/site_ruby/1.9.1/rubygems/source_index.rb:320 Gem::SourceIndex#refresh! is deprecated with no replacement It will be removed on or after 2011-11-01. called from /Users/alex/.rvm/rubies/ruby-1.9.2-p0/lib/ruby/site_ruby/1.9.1/rubygems/source_index.rb:95 Gem::SourceIndex#search is deprecated with no replacement It will be removed on or after 2011-11-01. called from /Users/alex/.rvm/rubies/ruby-1.9.2-p0/lib/ruby/site_ruby/1.9.1/rubygems/commands/rdoc_command.rb:64 Gem::SourceIndex#spec_dirs= is deprecated; use Specification.dirs= instead. It will be removed on or after 2011-11-01. called from /Users/alex/.rvm/rubies/ruby-1.9.2-p0/lib/ruby/site_ruby/1.9.1/rubygems/source_index.rb:94 Gem::SourceIndex.from_gems_in is deprecated with no replacement It will be removed on or after 2011-10-01. called from /Users/alex/.rvm/rubies/ruby-1.9.2-p0/lib/ruby/site_ruby/1.9.1/rubygems/source_index.rb:47 Gem::SourceIndex.from_installed_gems is deprecated with no replacement It will be removed on or after 2011-10-01. called from /Users/alex/.rvm/rubies/ruby-1.9.2-p0/lib/ruby/site_ruby/1.9.1/rubygems/commands/rdoc_command.rb:64 Gem::SourceIndex.installed_spec_directories is deprecated; use Specification.dirs instead. It will be removed on or after 2011-11-01. called from /Users/alex/.rvm/rubies/ruby-1.9.2-p0/lib/ruby/site_ruby/1.9.1/rubygems/source_index.rb:47 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29186&group_id=126 From noreply at rubyforge.org Wed May 11 23:53:17 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 11 May 2011 23:53:17 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29184 ] NOTE: Gem::Specification#default_executable= is deprecated with no replacement. Message-ID: <20110512035317.9D94F1858361@rubyforge.org> Bugs item #29184, was opened at 2011-05-08 12:27 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29184&group_id=126 Category: you broke my monkeypatch! Group: None Status: Closed Resolution: Rejected Priority: 3 Submitted By: Greg Hazel (ghazel) Assigned to: Ryan Davis (zenspider) Summary: NOTE: Gem::Specification#default_executable= is deprecated with no replacement. Initial Comment: Upgraded from 1.7.2 to 1.8.1 and got lots of messages like: Gem::Specification#default_executable= called from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/gems/1.8/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. "With no replacement" is not a very useful message, since it's not clear how to resolve this. Also, tons of gems cause this warning, so maybe the deprecation is not such a great idea. ---------------------------------------------------------------------- >Comment By: Greg Hazel (ghazel) Date: 2011-05-11 20:53 Message: How do you perform that operation in the new version of rubygems? ---------------------------------------------------------------------- Comment By: Greg Hazel (ghazel) Date: 2011-05-11 20:52 Message: I had not filed a ticket about "Gem::Specification#default_executable=" before. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-05-11 20:51 Message: dupe: repeating the exact same ticket multiple times does nothing. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29184&group_id=126 From noreply at rubyforge.org Wed May 11 23:54:12 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 11 May 2011 23:54:12 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29186 ] NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. Message-ID: <20110512035412.CDDA31858361@rubyforge.org> Bugs item #29186, was opened at 2011-05-08 12:31 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29186&group_id=126 Category: you broke my monkeypatch! Group: None Status: Closed Resolution: Rejected Priority: 3 Submitted By: Greg Hazel (ghazel) Assigned to: Ryan Davis (zenspider) Summary: NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. Initial Comment: Upgraded from 1.7.2 to 1.8.1, got deprecation errors about rubygems itself? NOTE: Gem::SourceIndex#load_gems_in is deprecated with no replacement. It will be removed on or after 2011-11-01. Gem::SourceIndex#load_gems_in called from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:320. 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 /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:127. These make no sense to me, since rubygems seems to be printing deprecation errors about its own code. The later, "NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec." is spammed easily 50 times. ---------------------------------------------------------------------- >Comment By: Greg Hazel (ghazel) Date: 2011-05-11 20:54 Message: Uh, you're not reading these, are you? "deprecated with no replacement" makes no sense. How do you perform these operations with the new version of rubygems? ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-05-11 20:53 Message: dupe. you're being a jackass both here and in IRC. ---------------------------------------------------------------------- Comment By: Alex Chaffee (alexch) Date: 2011-05-11 20:22 Message: I installed my patched version of RubyGems (see bug #29176) to get a better report and it looks like he's right: RubyGems 1.8 is complaining about its own code. Here's the list of 9 places where source_index.rb calls deprecated methods. pepper:rubygems [ruby-1.9.2-p0] alex$ gem rdoc bundler Error loading RubyGems plugin "/Users/alex/.rvm/gems/ruby-1.9.2-p0/gems/yard-0.6.4/lib/rubygems_plugin.rb": undefined method `overwrite_accessor' for Gem::Specification:Class (NoMethodError) Warning: Gem::SourceIndex.from_installed_gems is deprecated with no replacement It will be removed on or after 2011-10-01. (Further warnings suppressed until exit.) called from /Users/alex/.rvm/rubies/ruby-1.9.2-p0/lib/ruby/site_ruby/1.9.1/rubygems/commands/rdoc_command.rb:64 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. Gem::SourceIndex#add_spec is deprecated; use Specification.add_spec instead. It will be removed on or after 2011-11-01. called from /Users/alex/.rvm/rubies/ruby-1.9.2-p0/lib/ruby/site_ruby/1.9.1/rubygems/source_index.rb:127 Gem::SourceIndex#initialize is deprecated with no replacement It will be removed on or after 2011-11-01. called from /Users/alex/.rvm/rubies/ruby-1.9.2-p0/lib/ruby/site_ruby/1.9.1/rubygems/source_index.rb:67 Gem::SourceIndex#load_gems_in is deprecated with no replacement It will be removed on or after 2011-11-01. called from /Users/alex/.rvm/rubies/ruby-1.9.2-p0/lib/ruby/site_ruby/1.9.1/rubygems/source_index.rb:320 Gem::SourceIndex#refresh! is deprecated with no replacement It will be removed on or after 2011-11-01. called from /Users/alex/.rvm/rubies/ruby-1.9.2-p0/lib/ruby/site_ruby/1.9.1/rubygems/source_index.rb:95 Gem::SourceIndex#search is deprecated with no replacement It will be removed on or after 2011-11-01. called from /Users/alex/.rvm/rubies/ruby-1.9.2-p0/lib/ruby/site_ruby/1.9.1/rubygems/commands/rdoc_command.rb:64 Gem::SourceIndex#spec_dirs= is deprecated; use Specification.dirs= instead. It will be removed on or after 2011-11-01. called from /Users/alex/.rvm/rubies/ruby-1.9.2-p0/lib/ruby/site_ruby/1.9.1/rubygems/source_index.rb:94 Gem::SourceIndex.from_gems_in is deprecated with no replacement It will be removed on or after 2011-10-01. called from /Users/alex/.rvm/rubies/ruby-1.9.2-p0/lib/ruby/site_ruby/1.9.1/rubygems/source_index.rb:47 Gem::SourceIndex.from_installed_gems is deprecated with no replacement It will be removed on or after 2011-10-01. called from /Users/alex/.rvm/rubies/ruby-1.9.2-p0/lib/ruby/site_ruby/1.9.1/rubygems/commands/rdoc_command.rb:64 Gem::SourceIndex.installed_spec_directories is deprecated; use Specification.dirs instead. It will be removed on or after 2011-11-01. called from /Users/alex/.rvm/rubies/ruby-1.9.2-p0/lib/ruby/site_ruby/1.9.1/rubygems/source_index.rb:47 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29186&group_id=126 From noreply at rubyforge.org Thu May 12 03:36:44 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 12 May 2011 03:36:44 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29176 ] Scary warnings are scaring helpless developers who can't do a thing about it Message-ID: <20110512073644.D9D4215B8029@rubyforge.org> Bugs item #29176, was opened at 2011-05-06 16: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: Mike Bethany (mikbe) Date: 2011-05-12 03: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 19: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 14: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 05: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-11 00: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 23: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 21: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 13: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 12: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 14: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 12: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 04:56 Message: No worries. ---------------------------------------------------------------------- Comment By: Justin Collins (presidentbeef) Date: 2011-05-08 02:57 Message: Sorry, my mistake. I didn't notice that gem was called out specifically. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-05-08 02: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-08 02: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-08 02: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-08 01: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 18: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 17: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 16: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 16: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 16: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 Thu May 12 11:11:29 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 12 May 2011 11:11:29 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29176 ] Scary warnings are scaring helpless developers who can't do a thing about it Message-ID: <20110512151129.5B5811858367@rubyforge.org> Bugs item #29176, was opened at 2011-05-06 16: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: Scott Tadman (tadman) Date: 2011-05-12 11: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 03: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 19: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 14: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 05: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-11 00: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 23: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 21: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 13: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 12: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 14: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 12: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 04:56 Message: No worries. ---------------------------------------------------------------------- Comment By: Justin Collins (presidentbeef) Date: 2011-05-08 02:57 Message: Sorry, my mistake. I didn't notice that gem was called out specifically. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-05-08 02: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-08 02: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-08 02: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-08 01: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 18: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 17: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 16: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 16: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 16: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 Thu May 12 11:22:55 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 12 May 2011 11:22:55 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29176 ] Scary warnings are scaring helpless developers who can't do a thing about it Message-ID: <20110512152255.6CA72177994D@rubyforge.org> Bugs item #29176, was opened at 2011-05-06 17: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: Luis Lavena (luislavena) Date: 2011-05-12 12: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 12: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 04: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 20: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 15: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 06: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-11 01: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-11 00: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 22: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 14: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 13: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 15: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 13: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 05:56 Message: No worries. ---------------------------------------------------------------------- Comment By: Justin Collins (presidentbeef) Date: 2011-05-08 03:57 Message: Sorry, my mistake. I didn't notice that gem was called out specifically. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-05-08 03: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-08 03: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-08 03: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-08 02: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 19: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 18: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 17: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 17: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 17: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 Thu May 12 12:23:29 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 12 May 2011 12:23:29 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29188 ] rails 2.3.11 fails to load with rubygems 1.8.1 Message-ID: <20110512162329.5D78E1858367@rubyforge.org> Bugs item #29188, was opened at 2011-05-08 12:33 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29188&group_id=126 Category: other Group: None Status: Open Resolution: Rejected Priority: 3 Submitted By: Greg Hazel (ghazel) Assigned to: Ryan Davis (zenspider) Summary: rails 2.3.11 fails to load with rubygems 1.8.1 Initial Comment: Upgraded from 1.7.2 to 1.8.1, then a Rails 2.3.11 app failed to load: /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/gems/1.8/gems/rails-2.3.11/lib/rails/gem_dependency.rb:277:in `==': undefined method `name' for "POpen4":String (NoMethodError) from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/site_ruby/1.8/rubygems/dependency.rb:217:in `===' from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/site_ruby/1.8/rubygems/dependency.rb:217:in `matching_specs' from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/site_ruby/1.8/rubygems/specification.rb:539:in `find_all' from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/site_ruby/1.8/rubygems/specification.rb:403:in `each' from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/site_ruby/1.8/rubygems/specification.rb:402:in `each' from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/site_ruby/1.8/rubygems/dependency.rb:216:in `find_all' from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/site_ruby/1.8/rubygems/dependency.rb:216:in `matching_specs' from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/site_ruby/1.8/rubygems/dependency.rb:238:in `to_specs' from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/site_ruby/1.8/rubygems/dependency.rb:256:in `to_spec' from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/site_ruby/1.8/rubygems.rb:1182:in `gem' from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/gems/1.8/gems/rails-2.3.11/lib/rails/gem_dependency.rb:75:in `add_load_paths' from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/gems/1.8/gems/rails-2.3.11/lib/initializer.rb:301:in `add_gem_load_paths' from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/gems/1.8/gems/rails-2.3.11/lib/initializer.rb:301:in `each' from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/gems/1.8/gems/rails-2.3.11/lib/initializer.rb:301:in `add_gem_load_paths' from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/gems/1.8/gems/rails-2.3.11/lib/initializer.rb:132:in `process' from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/gems/1.8/gems/rails-2.3.11/lib/initializer.rb:113:in `send' from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/gems/1.8/gems/rails-2.3.11/lib/initializer.rb:113:in `run' ---------------------------------------------------------------------- >Comment By: Greg Hazel (ghazel) Date: 2011-05-12 09:23 Message: The first Rubygems commit where this error is reproducible is: https://github.com/rubygems/rubygems/commit/97932d63efbd35704c1669ea281a4701fe2ecb60 Although before that a different error is encountered, which started with this commit: https://github.com/rubygems/rubygems/commit/78a43480440f527c22452e1ae986206712959ef5 ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-05-11 20:32 Message: Cleaned up path that works in my rubygems checkout: rails-2.3.11/lib/rails/gem_dependency.rb:277:in `==': undefined method `name' for "POpen4":String (NoMethodError) from lib/rubygems/dependency.rb:217:in `===' from lib/rubygems/dependency.rb:217:in `matching_specs' from lib/rubygems/specification.rb:539:in `find_all' from lib/rubygems/specification.rb:403:in `each' from lib/rubygems/specification.rb:402:in `each' from lib/rubygems/dependency.rb:216:in `find_all' from lib/rubygems/dependency.rb:216:in `matching_specs' from lib/rubygems/dependency.rb:238:in `to_specs' from lib/rubygems/dependency.rb:256:in `to_spec' from lib/rubygems.rb:1182:in `gem' from rails-2.3.11/lib/rails/gem_dependency.rb:75:in `add_load_paths' from rails-2.3.11/lib/initializer.rb:301:in `add_gem_load_paths' from rails-2.3.11/lib/initializer.rb:301:in `each' from rails-2.3.11/lib/initializer.rb:301:in `add_gem_load_paths' from rails-2.3.11/lib/initializer.rb:132:in `process' from rails-2.3.11/lib/initializer.rb:113:in `send' from rails-2.3.11/lib/initializer.rb:113:in `run' gem_dependency.rb:277 is a buggy impl of #==: def ==(other) self.name == other.name && self.requirement == other.requirement end It's simply bad form to not check the class first. Not sure how that ever passed code review. That alone would probably fix the issue, but I'm not sure as I can't tell you why their call of #name returns another dep. Couple that with a very sketchy implementation: def add_load_paths self.class.add_frozen_gem_path return if @loaded || @load_paths_added if framework_gem? @load_paths_added = @loaded = @frozen = true return end gem self @spec = Gem.loaded_specs[name] @frozen = @spec.loaded_from.include?(self.class.unpacked_path) if @spec @load_paths_added = true rescue Gem::LoadError end `gem self` where self is a GemDependency (a subclass of our Gem::Dependency) just doesn't make sense. I'm not sure how this ever worked and it is possible it never did given that completely blithe rescue at the bottom... ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29188&group_id=126 From noreply at rubyforge.org Thu May 12 12:44:54 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 12 May 2011 12:44:54 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29176 ] Scary warnings are scaring helpless developers who can't do a thing about it Message-ID: <20110512164454.6DBFE1858375@rubyforge.org> Bugs item #29176, was opened at 2011-05-06 16: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: Scott Tadman (tadman) Date: 2011-05-12 12: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 11: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 11: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 03: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 19: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 14: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 05: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-11 00: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 23: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 21: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 13: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 12: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 14: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 12: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 04:56 Message: No worries. ---------------------------------------------------------------------- Comment By: Justin Collins (presidentbeef) Date: 2011-05-08 02:57 Message: Sorry, my mistake. I didn't notice that gem was called out specifically. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-05-08 02: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-08 02: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-08 02: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-08 01: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 18: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 17: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 16: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 16: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 16: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 Thu May 12 17:19:27 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 12 May 2011 17:19:27 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29176 ] Scary warnings are scaring helpless developers who can't do a thing about it Message-ID: <20110512211927.349C518583A8@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-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 Thu May 12 17:58:35 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 12 May 2011 17:58:35 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29176 ] Scary warnings are scaring helpless developers who can't do a thing about it Message-ID: <20110512215835.A323618583A8@rubyforge.org> Bugs item #29176, was opened at 2011-05-06 17: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: Luis Lavena (luislavena) Date: 2011-05-12 18: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 18: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 13: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 12: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 12: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 04: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 20: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 15: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 06: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-11 01: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-11 00: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 22: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 14: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 13: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 15: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 13: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 05:56 Message: No worries. ---------------------------------------------------------------------- Comment By: Justin Collins (presidentbeef) Date: 2011-05-08 03:57 Message: Sorry, my mistake. I didn't notice that gem was called out specifically. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-05-08 03: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-08 03: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-08 03: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-08 02: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 19: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 18: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 17: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 17: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 17: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 ryand-ruby at zenspider.com Thu May 12 20:39:31 2011 From: ryand-ruby at zenspider.com (Ryan Davis) Date: Thu, 12 May 2011 17:39:31 -0700 Subject: [Rubygems-developers] [ANN] isolate 3.0.1 Released Message-ID: isolate version 3.0.1 has been released! * Isolate is a very simple RubyGems sandbox. It provides a way to express and automatically install your project's Gem dependencies. Changes: ### 3.0.1 / 2011-05-11 * 6 minor enhancements: * Added Entry#to_s and #inspect to make it much more readable. * Added Isolate.sandbox= and used it from Hoe::Isolate plugin. * Deprecated Sandbox#index. * Entry#specification now returns nil if it doesn't resolve to anything. * Refactored Sandbox's default path so that tests won't collide with our Rakefile. * We now require rubygems >= 1.8.2. * 2 bug fixes: * Cleaned up all warnings caused by rubygems 1.8 deprecations. * Fixed Sandbox#legitimize! to properly deal with Gem::Dependency. From stephen.bannasch at deanbrook.org Fri May 13 10:55:11 2011 From: stephen.bannasch at deanbrook.org (Stephen Bannasch) Date: Fri, 13 May 2011 10:55:11 -0400 Subject: [Rubygems-developers] how are people using GEM_HOME and when (if ever) should it be ignored Message-ID: How are people using GEM_HOME, in what situations and when (if ever) should it be ignored. I recently fixed a bug in JRuby that so far would only be exposed to a user when they install jruby-head using RVM. rvm install jruby-head rewrite's the current rakes hash-bang invocation to be: #!/usr/bin/env jruby http://jira.codehaus.org/browse/JRUBY-5791 The problem occurred because during the install rvm had already defined GEM_HOME and it referenced a specific MRI Ruby that was not JRuby. Part of the ant distribution install scripts for JRuby install specific gems. When JRuby was running this task Gem.ruby referenced the JRuby executable but Gem.bindir referenced the original GEM_HOME defined when the install invocation was made. Before fixing this issue one of the results was that jruby installed it's gems into the MRI GEM_HOME. I modified the specific ant task to unset GEM_HOME during the install so the JRuby uses a gem home based on the executing JRuby instance. I realized also that if I have GEM_HOME defined and referencing a different Ruby VM and I just run JRuby directly it will also be running with Gem.ruby and Gem.bindir referencing resources in separate Ruby VMs. I've entered an issue in the JRuby issue tracker here: http://jira.codehaus.org/browse/JRUBY-5795 JRuby uses incorrect Gem.bindir when env var GEM_HOME points elsewhere It's not clear to me what should happen when one Ruby VM is running (with GEM_HOME defined) and another Ruby VM starts up in the same environment. I suspect this occurs infrequently but might happen more often with JRuby. Which leads me back to my initial question: how is GEM_HOME being used now? From ryand-ruby at zenspider.com Fri May 13 13:57:00 2011 From: ryand-ruby at zenspider.com (Ryan Davis) Date: Fri, 13 May 2011 10:57:00 -0700 Subject: [Rubygems-developers] how are people using GEM_HOME and when (if ever) should it be ignored In-Reply-To: References: Message-ID: <8BC21DF5-C13B-475A-9641-56BAEC60A518@zenspider.com> On May 13, 2011, at 07:55 , Stephen Bannasch wrote: > How are people using GEM_HOME, in what situations and when (if ever) should it be ignored. I don't know how to answer your "how" question, but your when question is: It shouldn't ever be ignored. > I recently fixed a bug in JRuby that so far would only be exposed to a user when they install jruby-head using RVM. > > rvm install jruby-head rewrite's the current rakes hash-bang > invocation to be: #!/usr/bin/env jruby > > http://jira.codehaus.org/browse/JRUBY-5791 > > The problem occurred because during the install rvm had already defined GEM_HOME and it referenced a specific MRI Ruby that was not JRuby. Part of the ant distribution install scripts for JRuby install specific gems. When JRuby was running this task Gem.ruby referenced the JRuby executable but Gem.bindir referenced the original GEM_HOME defined when the install invocation was made. > > Before fixing this issue one of the results was that jruby installed it's gems into the MRI GEM_HOME. Correct. All installs go into GEM_HOME. > I modified the specific ant task to unset GEM_HOME during the install so the JRuby uses a gem home based on the executing JRuby instance. That's probably the best way to do it if I'm understanding your problem correctly. I think this is only correct because you're inside the context of an ant task, and that's unambiguously jruby-space. > I realized also that if I have GEM_HOME defined and referencing a different Ruby VM and I just run JRuby directly it will also be running with Gem.ruby and Gem.bindir referencing resources in separate Ruby VMs. > > I've entered an issue in the JRuby issue tracker here: > > http://jira.codehaus.org/browse/JRUBY-5795 > JRuby uses incorrect Gem.bindir when env var GEM_HOME points elsewhere > > It's not clear to me what should happen when one Ruby VM is running (with GEM_HOME defined) and another Ruby VM starts up in the same environment. I suspect this occurs infrequently but might happen more often with JRuby. > > Which leads me back to my initial question: how is GEM_HOME being used now? GEM_HOME is essentially the writable portion of GEM_PATH. I think ticket 5795 is correct in that it CAN lead to confusing errors... but I think it is the way we should do it. I get bit once in a while because I do this in my shell setup: export GEM_PATH=`gem env home` and if I turn around and use ruby 1.9 it will cause problems with binary gems. Most of this is taken care of for me by using isolate in every project I work on, but that's a special case, not the norm. From ryand-ruby at zenspider.com Fri May 13 14:07:52 2011 From: ryand-ruby at zenspider.com (Ryan Davis) Date: Fri, 13 May 2011 11:07:52 -0700 Subject: [Rubygems-developers] how are people using GEM_HOME and when (if ever) should it be ignored In-Reply-To: References: Message-ID: <17857325-810B-4F33-894B-83E9D436D53B@zenspider.com> On May 13, 2011, at 07:55 , Stephen Bannasch wrote: > How are people using GEM_HOME, in what situations and when (if ever) should it be ignored. One additional note: I think this problem will only get worse over time and I don't have a good solution. In particular, I think GEM_HOME should die and we should only use GEM_PATH (where we only write into the first entry). I think that GEM_PATH should implicitly tack on something like isolate's multiruby suffix: suffix = "#{Gem.ruby_engine}-#{RbConfig::CONFIG['ruby_version']}" tho, it may be better to do something like 1.9's compatibility version instead. From noreply at rubyforge.org Fri May 13 14:42:31 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 13 May 2011 14:42:31 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29201 ] Do not show useless and obnoxious output to normal people, instead fix the problem Message-ID: <20110513184231.D077F177994D@rubyforge.org> Bugs item #29201, was opened at 2011-05-13 18:42 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29201&group_id=126 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Rich Meyers (richmeyers) Assigned to: Nobody (None) Summary: Do not show useless and obnoxious output to normal people, instead fix the problem Initial Comment: As you might be aware (http://blog.zenspider.com/ #1), rubygems 1.8.2 prints a bunch of messages like this: Gem::Specification#default_executable= called from /opt/ruby-enterprise-1.8.7-2010.02/lib/ruby/gems/1.8/specifications/treetop-1.4.9.gemspec:11. If you are not aware of issues this behavior is causing, please see here: http://stackoverflow.com/questions/5949521/how-do-i-fix-rubygems-recent-deprecation-warning http://pupeno.com/blog/getting-rid-of-rubygems-deprecation-warnings/ It appears that the solution for this problem is to run a(nother) gem command. Gem should run this command automatically as part of the upgrade, or installation. As a user I should not be tasked to fix the breakage that rubygems are inflicting on ruby gems (or the other way around). This report is brought to you courtesy of http://blog.zenspider.com/ #2. Thanks. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29201&group_id=126 From noreply at rubyforge.org Fri May 13 15:58:41 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 13 May 2011 15:58:41 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29201 ] Do not show useless and obnoxious output to normal people, instead fix the problem Message-ID: <20110513195841.BF3651858377@rubyforge.org> Bugs item #29201, was opened at 2011-05-13 11:42 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29201&group_id=126 Category: None Group: None >Status: Closed >Resolution: Rejected Priority: 3 Submitted By: Rich Meyers (richmeyers) Assigned to: Nobody (None) Summary: Do not show useless and obnoxious output to normal people, instead fix the problem Initial Comment: As you might be aware (http://blog.zenspider.com/ #1), rubygems 1.8.2 prints a bunch of messages like this: Gem::Specification#default_executable= called from /opt/ruby-enterprise-1.8.7-2010.02/lib/ruby/gems/1.8/specifications/treetop-1.4.9.gemspec:11. If you are not aware of issues this behavior is causing, please see here: http://stackoverflow.com/questions/5949521/how-do-i-fix-rubygems-recent-deprecation-warning http://pupeno.com/blog/getting-rid-of-rubygems-deprecation-warnings/ It appears that the solution for this problem is to run a(nother) gem command. Gem should run this command automatically as part of the upgrade, or installation. As a user I should not be tasked to fix the breakage that rubygems are inflicting on ruby gems (or the other way around). This report is brought to you courtesy of http://blog.zenspider.com/ #2. Thanks. ---------------------------------------------------------------------- >Comment By: Ryan Davis (zenspider) Date: 2011-05-13 12:58 Message: This rejection is brought to you courtesy of http://blog.zenspider.com/2011/05/rubygems-18-is-coming.html #2, addendum #1. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29201&group_id=126 From ryand-ruby at zenspider.com Fri May 13 16:36:51 2011 From: ryand-ruby at zenspider.com (Ryan Davis) Date: Fri, 13 May 2011 13:36:51 -0700 Subject: [Rubygems-developers] how are people using GEM_HOME and when (if ever) should it be ignored In-Reply-To: References: Message-ID: <2F4DA5A2-87D1-4BD4-9317-5EB69395D42B@zenspider.com> On May 13, 2011, at 07:55 , Stephen Bannasch wrote: > http://jira.codehaus.org/browse/JRUBY-5795 > JRuby uses incorrect Gem.bindir when env var GEM_HOME points elsewhere "What negative effect would occur if JRuby always in effect ignored the environmental variable GEM_HOME and instead used it's gem directory?" You'll break tools like bundler, isolate, rvm, and anything else that assumes that rubygems behaves normally. I suspect you'll break more than you fix by having jruby override and ignore GEM_HOME. From noreply at rubyforge.org Fri May 13 17:01:48 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 13 May 2011 17:01:48 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29188 ] rails 2.3.11 fails to load with rubygems 1.8.1 Message-ID: <20110513210148.F3EF11858372@rubyforge.org> Bugs item #29188, was opened at 2011-05-08 19:33 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29188&group_id=126 Category: other Group: None Status: Open Resolution: Rejected Priority: 3 Submitted By: Greg Hazel (ghazel) Assigned to: Ryan Davis (zenspider) Summary: rails 2.3.11 fails to load with rubygems 1.8.1 Initial Comment: Upgraded from 1.7.2 to 1.8.1, then a Rails 2.3.11 app failed to load: /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/gems/1.8/gems/rails-2.3.11/lib/rails/gem_dependency.rb:277:in `==': undefined method `name' for "POpen4":String (NoMethodError) from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/site_ruby/1.8/rubygems/dependency.rb:217:in `===' from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/site_ruby/1.8/rubygems/dependency.rb:217:in `matching_specs' from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/site_ruby/1.8/rubygems/specification.rb:539:in `find_all' from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/site_ruby/1.8/rubygems/specification.rb:403:in `each' from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/site_ruby/1.8/rubygems/specification.rb:402:in `each' from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/site_ruby/1.8/rubygems/dependency.rb:216:in `find_all' from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/site_ruby/1.8/rubygems/dependency.rb:216:in `matching_specs' from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/site_ruby/1.8/rubygems/dependency.rb:238:in `to_specs' from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/site_ruby/1.8/rubygems/dependency.rb:256:in `to_spec' from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/site_ruby/1.8/rubygems.rb:1182:in `gem' from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/gems/1.8/gems/rails-2.3.11/lib/rails/gem_dependency.rb:75:in `add_load_paths' from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/gems/1.8/gems/rails-2.3.11/lib/initializer.rb:301:in `add_gem_load_paths' from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/gems/1.8/gems/rails-2.3.11/lib/initializer.rb:301:in `each' from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/gems/1.8/gems/rails-2.3.11/lib/initializer.rb:301:in `add_gem_load_paths' from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/gems/1.8/gems/rails-2.3.11/lib/initializer.rb:132:in `process' from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/gems/1.8/gems/rails-2.3.11/lib/initializer.rb:113:in `send' from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/gems/1.8/gems/rails-2.3.11/lib/initializer.rb:113:in `run' ---------------------------------------------------------------------- Comment By: Roger Pack (rogerdpack) Date: 2011-05-13 21:01 Message: Just ran into this, too. http://betterlogic.com/roger/2011/05/undefined-method/ ---------------------------------------------------------------------- Comment By: Greg Hazel (ghazel) Date: 2011-05-12 16:23 Message: The first Rubygems commit where this error is reproducible is: https://github.com/rubygems/rubygems/commit/97932d63efbd35704c1669ea281a4701fe2ecb60 Although before that a different error is encountered, which started with this commit: https://github.com/rubygems/rubygems/commit/78a43480440f527c22452e1ae986206712959ef5 ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-05-12 03:32 Message: Cleaned up path that works in my rubygems checkout: rails-2.3.11/lib/rails/gem_dependency.rb:277:in `==': undefined method `name' for "POpen4":String (NoMethodError) from lib/rubygems/dependency.rb:217:in `===' from lib/rubygems/dependency.rb:217:in `matching_specs' from lib/rubygems/specification.rb:539:in `find_all' from lib/rubygems/specification.rb:403:in `each' from lib/rubygems/specification.rb:402:in `each' from lib/rubygems/dependency.rb:216:in `find_all' from lib/rubygems/dependency.rb:216:in `matching_specs' from lib/rubygems/dependency.rb:238:in `to_specs' from lib/rubygems/dependency.rb:256:in `to_spec' from lib/rubygems.rb:1182:in `gem' from rails-2.3.11/lib/rails/gem_dependency.rb:75:in `add_load_paths' from rails-2.3.11/lib/initializer.rb:301:in `add_gem_load_paths' from rails-2.3.11/lib/initializer.rb:301:in `each' from rails-2.3.11/lib/initializer.rb:301:in `add_gem_load_paths' from rails-2.3.11/lib/initializer.rb:132:in `process' from rails-2.3.11/lib/initializer.rb:113:in `send' from rails-2.3.11/lib/initializer.rb:113:in `run' gem_dependency.rb:277 is a buggy impl of #==: def ==(other) self.name == other.name && self.requirement == other.requirement end It's simply bad form to not check the class first. Not sure how that ever passed code review. That alone would probably fix the issue, but I'm not sure as I can't tell you why their call of #name returns another dep. Couple that with a very sketchy implementation: def add_load_paths self.class.add_frozen_gem_path return if @loaded || @load_paths_added if framework_gem? @load_paths_added = @loaded = @frozen = true return end gem self @spec = Gem.loaded_specs[name] @frozen = @spec.loaded_from.include?(self.class.unpacked_path) if @spec @load_paths_added = true rescue Gem::LoadError end `gem self` where self is a GemDependency (a subclass of our Gem::Dependency) just doesn't make sense. I'm not sure how this ever worked and it is possible it never did given that completely blithe rescue at the bottom... ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29188&group_id=126 From noreply at rubyforge.org Fri May 13 17:42:05 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 13 May 2011 17:42:05 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29202 ] gem build should force standard date format in metadata file Message-ID: <20110513214205.856BB1858374@rubyforge.org> Bugs item #29202, was opened at 2011-05-13 17:42 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29202&group_id=126 Category: `gem` commands (other) Group: None Status: Open Resolution: None Priority: 3 Submitted By: Mike Bethany (mikbe) Assigned to: Nobody (None) Summary: gem build should force standard date format in metadata file Initial Comment: **Description:** When building a gem the date format used on my OS X machines is incompatible with the date format used on my Ubuntu 10.10 virtual machines. OS X uses the following format: date: 2011-05-13 00:00:00.000000000Z Where as on Ubuntu the date format is: date: 2011-05-13 00:00:00 Z **Error message on Ubuntu (but not OS X):** Invalid gemspec in [/usr/local/ruby/lib/ruby/gems/1.9.1/specifications/osx_vs_ubuntu-0.0.1.gemspec]: invalid date format in specification: "2011-05-13 00:00:00.000000000Z" /usr/local/ruby/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:277:in `block in _resort!': undefined method `name' for nil:NilClass (NoMethodError) from /usr/local/ruby/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:276:in `sort!' from /usr/local/ruby/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:276:in `_resort!' from /usr/local/ruby/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:270:in `_all' from /usr/local/ruby/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:402:in `each' from /usr/local/ruby/lib/ruby/site_ruby/1.9.1/rubygems/dependency.rb:216:in `find_all' from /usr/local/ruby/lib/ruby/site_ruby/1.9.1/rubygems/dependency.rb:216:in `matching_specs' from /usr/local/ruby/lib/ruby/site_ruby/1.9.1/rubygems/dependency.rb:238:in `to_specs' from /usr/local/ruby/lib/ruby/site_ruby/1.9.1/rubygems/dependency.rb:256:in `to_spec' from /usr/local/ruby/lib/ruby/site_ruby/1.9.1/rubygems.rb:1182:in `gem' from /usr/local/ruby/bin/rake:18:in `
' **Steps to replicate:** Create a gem app: $ bundler gem osx_vs_ubuntu $ cd osx_vs_ubuntu $ git add . $ git commit -am "initial commit" Edit gemspec file setting: authors, email, summary, and description. Build the app on OS X machine: $ rake build Copy gem to an Ubuntu machine. Install gem on Ubuntu machine. $ gem install osx_vs_ubuntu-0.0.1.gem Invalid gemspec in [/usr/local/ruby/lib/ruby/gems/1.9.1/specifications/osx_vs_ubuntu-0.0.1.gemspec]: invalid date format in specification: "2011-05-13 00:00:00.000000000Z" ERROR: While executing gem ... (NoMethodError) undefined method `name' for nil:NilClass **Work arounds** * Build the gem on an Ubuntu machine. * Uncompress the gem file, uncompress the metadata file, edit the metadata file to use Ubuntu format, recompress metadatafile, recompress gem file. Hardcoding the date format in the gemspec file to the Ubuntu version does not help. The date is redone when the gem is built. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29202&group_id=126 From noreply at rubyforge.org Fri May 13 19:15:29 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 13 May 2011 19:15:29 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29201 ] Do not show useless and obnoxious output to normal people, instead fix the problem Message-ID: <20110513231529.84F77185837F@rubyforge.org> Bugs item #29201, was opened at 2011-05-13 18:42 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29201&group_id=126 Category: None Group: None Status: Closed Resolution: Rejected Priority: 3 Submitted By: Rich Meyers (richmeyers) Assigned to: Nobody (None) Summary: Do not show useless and obnoxious output to normal people, instead fix the problem Initial Comment: As you might be aware (http://blog.zenspider.com/ #1), rubygems 1.8.2 prints a bunch of messages like this: Gem::Specification#default_executable= called from /opt/ruby-enterprise-1.8.7-2010.02/lib/ruby/gems/1.8/specifications/treetop-1.4.9.gemspec:11. If you are not aware of issues this behavior is causing, please see here: http://stackoverflow.com/questions/5949521/how-do-i-fix-rubygems-recent-deprecation-warning http://pupeno.com/blog/getting-rid-of-rubygems-deprecation-warnings/ It appears that the solution for this problem is to run a(nother) gem command. Gem should run this command automatically as part of the upgrade, or installation. As a user I should not be tasked to fix the breakage that rubygems are inflicting on ruby gems (or the other way around). This report is brought to you courtesy of http://blog.zenspider.com/ #2. Thanks. ---------------------------------------------------------------------- >Comment By: Rich Meyers (richmeyers) Date: 2011-05-13 23:15 Message: Good job. This single decision is going to result in person-years (I am not exaggerating this one bit) of wasted effort by ruby developers. I wonder what you were expecting, a shower of gifts and gratitude from the people whose time you wasted and no doubt will waste again? Clearly when you wrote that blog post you knew what you were doing. Maybe you knew the full ramifications then, maybe you did not and maybe you still are trying to convince yourself that it is no big deal. Well, it *is* a big deal and what you said applies first and foremost to yourself. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-05-13 19:58 Message: This rejection is brought to you courtesy of http://blog.zenspider.com/2011/05/rubygems-18-is-coming.html #2, addendum #1. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29201&group_id=126 From luislavena at gmail.com Sat May 14 14:21:40 2011 From: luislavena at gmail.com (Luis Lavena) Date: Sat, 14 May 2011 15:21:40 -0300 Subject: [Rubygems-developers] Gem::Specification.files, I'm getting crazy? Message-ID: Hello, I'm about to loose my mind, so before that happens, want to email here just to confirm and reserve my room in the asylum... When I generated rake-compiler 0.7.8 gemspec, I used RubyGems 1.7.2: https://gist.github.com/972473 As you can see there, files contains all the files found in the gemspec. On RubyGems 1.8.2, after `gem pristine` or a new installation of that gem, the files section of the gemspec only contain executables and readme: https://gist.github.com/972479 Not even lib files are listed. So, when doing `Gem::Specification.find_by_name "rake-compiler"` I get this for .files: >> gemspec.lib_files => [] >> gemspec.files => ["bin/rake-compiler", "README.rdoc", "LICENSE.txt", "History.txt"] What I'm missing? -- 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 Sat May 14 15:46:59 2011 From: jftucker at gmail.com (James Tucker) Date: Sat, 14 May 2011 12:46:59 -0700 Subject: [Rubygems-developers] Gem::Specification.files, I'm getting crazy? In-Reply-To: References: Message-ID: <6AADB423-B30F-4A42-A60B-4BFDD2EA0C09@gmail.com> On May 14, 2011, at 11:21 AM, Luis Lavena wrote: > Hello, > > I'm about to loose my mind, so before that happens, want to email here > just to confirm and reserve my room in the asylum... > > When I generated rake-compiler 0.7.8 gemspec, I used RubyGems 1.7.2: > https://gist.github.com/972473 > > As you can see there, files contains all the files found in the gemspec. > > On RubyGems 1.8.2, after `gem pristine` or a new installation of that > gem, the files section of the gemspec only contain executables and > readme: > > https://gist.github.com/972479 > > Not even lib files are listed. > > > So, when doing `Gem::Specification.find_by_name "rake-compiler"` I get > this for .files: > >>> gemspec.lib_files > => [] > >>> gemspec.files > => ["bin/rake-compiler", "README.rdoc", "LICENSE.txt", "History.txt"] > > What I'm missing? I did this to save a huge amount of wasted ram and memory fragmentation. http://blog.ra66i.org/archives/2011/02/rubygems-no-longer-chews-on-ram/ > -- > 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 luislavena at gmail.com Sat May 14 16:13:07 2011 From: luislavena at gmail.com (Luis Lavena) Date: Sat, 14 May 2011 17:13:07 -0300 Subject: [Rubygems-developers] Gem::Specification.files, I'm getting crazy? In-Reply-To: <6AADB423-B30F-4A42-A60B-4BFDD2EA0C09@gmail.com> References: <6AADB423-B30F-4A42-A60B-4BFDD2EA0C09@gmail.com> Message-ID: On Sat, May 14, 2011 at 4:46 PM, James Tucker wrote: > > [snip] > > I did this to save a huge amount of wasted ram and memory fragmentation. http://blog.ra66i.org/archives/2011/02/rubygems-no-longer-chews-on-ram/ > Aha, good, so what should I use then? Not all the gems have a manifest file that I can use to know what to copy from it. I don't want to copy any gem compilation artifacts since I'm comsolidating the contents of the gems to reduce the LOAD_PATH. On a sidenote, having files showing these incomplete information is useless, or having README.rdoc or bin/* files there since Gem.bin_path already provides access to the binary files. Would really appreciate a workaround to this without the need to open the gems and read the yaml directly. 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 jftucker at gmail.com Sat May 14 16:59:58 2011 From: jftucker at gmail.com (James Tucker) Date: Sat, 14 May 2011 13:59:58 -0700 Subject: [Rubygems-developers] Gem::Specification.files, I'm getting crazy? In-Reply-To: References: <6AADB423-B30F-4A42-A60B-4BFDD2EA0C09@gmail.com> Message-ID: <93152763-9858-4C6D-AF48-FE7EEBAFA92B@gmail.com> On May 14, 2011, at 1:13 PM, Luis Lavena wrote: > On Sat, May 14, 2011 at 4:46 PM, James Tucker wrote: >> >> [snip] >> >> I did this to save a huge amount of wasted ram and memory fragmentation. http://blog.ra66i.org/archives/2011/02/rubygems-no-longer-chews-on-ram/ >> > > Aha, good, so what should I use then? > > Not all the gems have a manifest file that I can use to know what to > copy from it. > > I don't want to copy any gem compilation artifacts since I'm > comsolidating the contents of the gems to reduce the LOAD_PATH. Everything in Gem.lib_paths. Builds are copied into lib in the standard mkmf system. > On a sidenote, having files showing these incomplete information is > useless, or having README.rdoc or bin/* files there since Gem.bin_path > already provides access to the binary files. That's forced by specification defaults, and should probably be adjusted. > Would really appreciate a workaround to this without the need to open > the gems and read the yaml directly. It'd be nice to not have to corrupt the gemspecs to do this. Ideally, what someone would produce is a more minimal artifact for the purposes of setting up the load path, shared path, bin path and dependencies. Ideally this would be created on install and removed on uninstall, and replace the usage of gemspecs at runtime. Careful coordination is required to still support gem list -d, etc. > > 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 > _______________________________________________ > Rubygems-developers mailing list > http://rubyforge.org/projects/rubygems > Rubygems-developers at rubyforge.org > http://rubyforge.org/mailman/listinfo/rubygems-developers From ryand-ruby at zenspider.com Sat May 14 20:08:48 2011 From: ryand-ruby at zenspider.com (Ryan Davis) Date: Sat, 14 May 2011 17:08:48 -0700 Subject: [Rubygems-developers] [ANN] isolate 3.0.2 Released Message-ID: <2DE51C13-ED3D-4576-8C75-AB0988423957@zenspider.com> isolate version 3.0.2 has been released! * Isolate is a very simple RubyGems sandbox. It provides a way to express and automatically install your project's Gem dependencies. Changes: ### 3.0.2 / 2011-05-14 * 3 bug fixes: * Cleanup shouldn't try to uninstall specs outside of our sandbox. * Pass spec.base_dir to the uninstaller during cleanup. * We shouldn't manipulate Gem.path, but if we do, we should be smart/clean about it. From luislavena at gmail.com Sun May 15 08:36:37 2011 From: luislavena at gmail.com (Luis Lavena) Date: Sun, 15 May 2011 09:36:37 -0300 Subject: [Rubygems-developers] Gem::Specification.files, I'm getting crazy? In-Reply-To: <93152763-9858-4C6D-AF48-FE7EEBAFA92B@gmail.com> References: <6AADB423-B30F-4A42-A60B-4BFDD2EA0C09@gmail.com> <93152763-9858-4C6D-AF48-FE7EEBAFA92B@gmail.com> Message-ID: On Sat, May 14, 2011 at 5:59 PM, James Tucker wrote: > > On May 14, 2011, at 1:13 PM, Luis Lavena wrote: > >> >> I don't want to copy any gem compilation artifacts since I'm >> comsolidating the contents of the gems to reduce the LOAD_PATH. > > Everything in Gem.lib_paths. Builds are copied into lib in the standard mkmf system. > There are some gems that do File.read to read the VERSION file in the root of the gem. I know, I know... I'm not the author, just the messenger, don't kill me. I also need to copy app/** of some gems that are Rails engines. This worked before using Gem::Specification#files, but not now :-( Guess will have to have my own exclusion pattern and use globing on the gem directory. 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 jftucker at gmail.com Sun May 15 16:13:46 2011 From: jftucker at gmail.com (James Tucker) Date: Sun, 15 May 2011 13:13:46 -0700 Subject: [Rubygems-developers] Gem::Specification.files, I'm getting crazy? In-Reply-To: References: <6AADB423-B30F-4A42-A60B-4BFDD2EA0C09@gmail.com> <93152763-9858-4C6D-AF48-FE7EEBAFA92B@gmail.com> Message-ID: On May 15, 2011, at 5:36 AM, Luis Lavena wrote: > On Sat, May 14, 2011 at 5:59 PM, James Tucker wrote: >> >> On May 14, 2011, at 1:13 PM, Luis Lavena wrote: >> >>> >>> I don't want to copy any gem compilation artifacts since I'm >>> comsolidating the contents of the gems to reduce the LOAD_PATH. >> >> Everything in Gem.lib_paths. Builds are copied into lib in the standard mkmf system. >> > > There are some gems that do File.read to read the VERSION file in the > root of the gem. mmm. > > I know, I know... I'm not the author, just the messenger, don't kill me. > > I also need to copy app/** of some gems that are Rails engines. shared would be better :-( > This worked before using Gem::Specification#files, but not now :-( > > Guess will have to have my own exclusion pattern and use globing on > the gem directory. possibly, or just dump them all over the top of each other and clean out common build artifacts. > > 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 > _______________________________________________ > Rubygems-developers mailing list > http://rubyforge.org/projects/rubygems > Rubygems-developers at rubyforge.org > http://rubyforge.org/mailman/listinfo/rubygems-developers From jon.forums at gmail.com Mon May 16 11:09:21 2011 From: jon.forums at gmail.com (Jon) Date: Mon, 16 May 2011 11:09:21 -0400 Subject: [Rubygems-developers] successful 1.8.2 --user-install upgrades? Message-ID: <20110516110921.21565ac8.jon.forums@gmail.com> If anyone has successfully upgraded to 1.8.2 on Linux and removed the deprecation messages, I'd appreciate the punchline. I've not looked into it (typical Monday) enough to determine if it's a bug or my misconfiguration, but will post to the bug tracker if needed. No complaints with updating multiple 1.8.7, 1.9.2, and 1.9.3dev Windows systems and doing the "gem pristine --all --no-extensions" and "gem pristine " dance. But I can't get my dev Arch system with gem's installed via --user-install (thin, rdiscount, erubis, mustache, rack, treetop) to stop squawking after doing "sudo gem update --system" and various "gem pristine" incantations. As this is a dev box, I'm OK if the fix is to reinstall all gems (and RG) as system gems. Jon --- blog: http://jonforums.github.com/ twitter: @jonforums From ryand-ruby at zenspider.com Mon May 16 18:18:43 2011 From: ryand-ruby at zenspider.com (Ryan Davis) Date: Mon, 16 May 2011 15:18:43 -0700 Subject: [Rubygems-developers] successful 1.8.2 --user-install upgrades? In-Reply-To: <20110516110921.21565ac8.jon.forums@gmail.com> References: <20110516110921.21565ac8.jon.forums@gmail.com> Message-ID: On May 16, 2011, at 08:09 , Jon wrote: > If anyone has successfully upgraded to 1.8.2 on Linux and removed the deprecation messages, I'd appreciate the punchline. I've not looked into it (typical Monday) enough to determine if it's a bug or my misconfiguration, but will post to the bug tracker if needed. > > No complaints with updating multiple 1.8.7, 1.9.2, and 1.9.3dev Windows systems and doing the "gem pristine --all --no-extensions" and "gem pristine " dance. > > But I can't get my dev Arch system with gem's installed via --user-install (thin, rdiscount, erubis, mustache, rack, treetop) to stop squawking after doing "sudo gem update --system" and various "gem pristine" incantations. As this is a dev box, I'm OK if the fix is to reinstall all gems (and RG) as system gems. Unfortunately with your problem description I can only guess as to what you have setup and how. With my guess, I can't repro: % sudo gem update --system 1.3.7 --no-rdoc --no-ri ... % gem i --user-install thin ... % sudo gem update --system 1.8.2 --no-rdoc --no-ri 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/ryan/.gem/ruby/1.8/specifications/thin-1.2.11.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 /Users/ryan/.gem/ruby/1.8/specifications/thin-1.2.11.gemspec:10. RubyGems 1.8.2 installed ... 3032 % gem list 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/ryan/.gem/ruby/1.8/specifications/thin-1.2.11.gemspec:10. *** LOCAL GEMS *** 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/ryan/.gem/ruby/1.8/specifications/thin-1.2.11.gemspec:10. eventmachine (0.12.10) hoe (2.9.4) hoe-seattlerb (1.2.5) isolate (3.0.2) minitest (2.1.0) playpen (1.1.0) rake (0.8.7) rdoc (3.5.3) rubygems-update (1.7.2, 1.3.7) thin (1.2.11) ZenTest (4.5.0) 3047 % gem pristine thin 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/ryan/.gem/ruby/1.8/specifications/thin-1.2.11.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 /Users/ryan/.gem/ruby/1.8/specifications/thin-1.2.11.gemspec:10. Restoring gems to pristine condition... Building native extensions. This could take a while... Restored thin-1.2.11 3048 % gem list *** LOCAL GEMS *** eventmachine (0.12.10) hoe (2.9.4) hoe-seattlerb (1.2.5) isolate (3.0.2) minitest (2.1.0) playpen (1.1.0) rake (0.8.7) rdoc (3.5.3) rubygems-update (1.7.2, 1.3.7) thin (1.2.11) ZenTest (4.5.0) From jon.forums at gmail.com Tue May 17 10:14:23 2011 From: jon.forums at gmail.com (Jon) Date: Tue, 17 May 2011 10:14:23 -0400 Subject: [Rubygems-developers] successful 1.8.2 --user-install upgrades? In-Reply-To: References: <20110516110921.21565ac8.jon.forums@gmail.com> Message-ID: <20110517101423.a7d9fde5.jon.forums@gmail.com> > Unfortunately with your problem description I can only guess as to what you have setup and how. > > With my guess, I can't repro: > > % sudo gem update --system 1.3.7 --no-rdoc --no-ri > ... > % gem i --user-install thin You're guess on setup is spot on...it's got to be my misconfiguration. Thanks for the details from trying to repro. Jon --- blog: http://jonforums.github.com/ twitter: @jonforums From ryand-ruby at zenspider.com Tue May 17 19:16:54 2011 From: ryand-ruby at zenspider.com (Ryan Davis) Date: Tue, 17 May 2011 16:16:54 -0700 Subject: [Rubygems-developers] successful 1.8.2 --user-install upgrades? In-Reply-To: <20110517101423.a7d9fde5.jon.forums@gmail.com> References: <20110516110921.21565ac8.jon.forums@gmail.com> <20110517101423.a7d9fde5.jon.forums@gmail.com> Message-ID: On May 17, 2011, at 07:14 , Jon wrote: >> Unfortunately with your problem description I can only guess as to what you have setup and how. >> >> With my guess, I can't repro: >> >> % sudo gem update --system 1.3.7 --no-rdoc --no-ri >> ... >> % gem i --user-install thin > > You're guess on setup is spot on...it's got to be my misconfiguration. Thanks for the details from trying to repro. If you figure out WHAT it is, can you point me at it before you fix it? From noreply at rubyforge.org Wed May 18 16:45:35 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 18 May 2011 16:45:35 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29176 ] Scary warnings are scaring helpless developers who can't do a thing about it Message-ID: <20110518204535.A43EF3C8087@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-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 Wed May 18 18:25:05 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 18 May 2011 18:25:05 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29181 ] RubyGems date spec field causing issues Message-ID: <20110518222505.22EA8167816A@rubyforge.org> Bugs item #29181, was opened at 2011-05-07 06:42 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29181&group_id=126 Category: other Group: None Status: Open Resolution: None Priority: 5 Submitted By: Luis Lavena (luislavena) Assigned to: Ryan Davis (zenspider) Summary: RubyGems date spec field causing issues Initial Comment: A new gem just released by one of the RubyInstaller contributors generated this: http://groups.google.com/group/rubyinstaller/msg/6a0b05d51811f5bc A simple gem, generated with Ruby 1.9.2 causes date to be generated incorrectly: Ruby 1.9.2 with RubyGems 1.8.1 date: 2011-05-07 00:00:00.000000000Z Ruby 1.8.7 with RubyGems 1.8.1: date: 2011-05-07 00:00:00 Z Installing that gem causes this: Invalid gemspec in [C:/Users/Luis/.gem/ruby/x86-mingw32/1.8/specifications/autotest-snarl-0.0.2.gemspec]: invalid date format in specification: "2011-05-07 00:00:00.000000000Z" C:/Users/Luis/Tools/ruby/ruby-1.8.7-p334-i386-mingw32/lib/ruby/site_ruby/1.8/rubygems/specification.rb:277:in `_resort!': undefined method `name' for nil:NilClass (NoMethodError) Not during installation but later in the process. You can reproduce this using my simple gem here: https://github.com/luislavena/autotest-snarl I don't use anything that is not RubyGems and Rake to generate it (even use Gem::PackageTask) ---------------------------------------------------------------------- Comment By: Alex Chaffee (alexch) Date: 2011-05-18 15:25 Message: Verified on Ruby 1.9.2p180. This seems to have happened sometime between 1.9.2-p0 and 1.9.2-p180, but I haven't yet done the regression to confirm. I know 1.8.7 works OK. To summarize: using MRI 1.9.2p180 to generate a gem results in an invalid date format. Workaround: use an older version or Ruby when *building* the gem. And do "gem specification pkg/foo-1.2.3.gem | grep date" to verify that your date is in the proper format before pushing to gemcutter. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29181&group_id=126 From noreply at rubyforge.org Wed May 18 18:57:28 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 18 May 2011 18:57:28 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29181 ] RubyGems date spec field causing issues Message-ID: <20110518225728.C855B18583A9@rubyforge.org> Bugs item #29181, was opened at 2011-05-07 06:42 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29181&group_id=126 Category: other Group: None Status: Open Resolution: None Priority: 5 Submitted By: Luis Lavena (luislavena) Assigned to: Ryan Davis (zenspider) Summary: RubyGems date spec field causing issues Initial Comment: A new gem just released by one of the RubyInstaller contributors generated this: http://groups.google.com/group/rubyinstaller/msg/6a0b05d51811f5bc A simple gem, generated with Ruby 1.9.2 causes date to be generated incorrectly: Ruby 1.9.2 with RubyGems 1.8.1 date: 2011-05-07 00:00:00.000000000Z Ruby 1.8.7 with RubyGems 1.8.1: date: 2011-05-07 00:00:00 Z Installing that gem causes this: Invalid gemspec in [C:/Users/Luis/.gem/ruby/x86-mingw32/1.8/specifications/autotest-snarl-0.0.2.gemspec]: invalid date format in specification: "2011-05-07 00:00:00.000000000Z" C:/Users/Luis/Tools/ruby/ruby-1.8.7-p334-i386-mingw32/lib/ruby/site_ruby/1.8/rubygems/specification.rb:277:in `_resort!': undefined method `name' for nil:NilClass (NoMethodError) Not during installation but later in the process. You can reproduce this using my simple gem here: https://github.com/luislavena/autotest-snarl I don't use anything that is not RubyGems and Rake to generate it (even use Gem::PackageTask) ---------------------------------------------------------------------- Comment By: Alex Chaffee (alexch) Date: 2011-05-18 15:57 Message: Confirmed: Building the gem with 1.9.2p180 makes a metadata field with a different date format than building the gem with 1.9.2p0. And that new format is unreadable by older versions of Ruby. I think it's that they added fractional seconds to the time, and the poor old date parser breaks when it hits ".0000000". It looks like Gem is just using "to_yaml" to turn the spec into the metadata file (builder.rb:79), so this isn't something that can be fixed with a simple strftime format tweak. See also bug #29202 ---------------------------------------------------------------------- Comment By: Alex Chaffee (alexch) Date: 2011-05-18 15:25 Message: Verified on Ruby 1.9.2p180. This seems to have happened sometime between 1.9.2-p0 and 1.9.2-p180, but I haven't yet done the regression to confirm. I know 1.8.7 works OK. To summarize: using MRI 1.9.2p180 to generate a gem results in an invalid date format. Workaround: use an older version or Ruby when *building* the gem. And do "gem specification pkg/foo-1.2.3.gem | grep date" to verify that your date is in the proper format before pushing to gemcutter. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29181&group_id=126 From noreply at rubyforge.org Wed May 18 18:59:48 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 18 May 2011 18:59:48 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29202 ] gem build should force standard date format in metadata file Message-ID: <20110518225948.4D7AC18583A9@rubyforge.org> Bugs item #29202, was opened at 2011-05-13 14:42 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29202&group_id=126 Category: `gem` commands (other) Group: None Status: Open Resolution: None Priority: 3 Submitted By: Mike Bethany (mikbe) Assigned to: Nobody (None) Summary: gem build should force standard date format in metadata file Initial Comment: **Description:** When building a gem the date format used on my OS X machines is incompatible with the date format used on my Ubuntu 10.10 virtual machines. OS X uses the following format: date: 2011-05-13 00:00:00.000000000Z Where as on Ubuntu the date format is: date: 2011-05-13 00:00:00 Z **Error message on Ubuntu (but not OS X):** Invalid gemspec in [/usr/local/ruby/lib/ruby/gems/1.9.1/specifications/osx_vs_ubuntu-0.0.1.gemspec]: invalid date format in specification: "2011-05-13 00:00:00.000000000Z" /usr/local/ruby/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:277:in `block in _resort!': undefined method `name' for nil:NilClass (NoMethodError) from /usr/local/ruby/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:276:in `sort!' from /usr/local/ruby/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:276:in `_resort!' from /usr/local/ruby/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:270:in `_all' from /usr/local/ruby/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:402:in `each' from /usr/local/ruby/lib/ruby/site_ruby/1.9.1/rubygems/dependency.rb:216:in `find_all' from /usr/local/ruby/lib/ruby/site_ruby/1.9.1/rubygems/dependency.rb:216:in `matching_specs' from /usr/local/ruby/lib/ruby/site_ruby/1.9.1/rubygems/dependency.rb:238:in `to_specs' from /usr/local/ruby/lib/ruby/site_ruby/1.9.1/rubygems/dependency.rb:256:in `to_spec' from /usr/local/ruby/lib/ruby/site_ruby/1.9.1/rubygems.rb:1182:in `gem' from /usr/local/ruby/bin/rake:18:in `
' **Steps to replicate:** Create a gem app: $ bundler gem osx_vs_ubuntu $ cd osx_vs_ubuntu $ git add . $ git commit -am "initial commit" Edit gemspec file setting: authors, email, summary, and description. Build the app on OS X machine: $ rake build Copy gem to an Ubuntu machine. Install gem on Ubuntu machine. $ gem install osx_vs_ubuntu-0.0.1.gem Invalid gemspec in [/usr/local/ruby/lib/ruby/gems/1.9.1/specifications/osx_vs_ubuntu-0.0.1.gemspec]: invalid date format in specification: "2011-05-13 00:00:00.000000000Z" ERROR: While executing gem ... (NoMethodError) undefined method `name' for nil:NilClass **Work arounds** * Build the gem on an Ubuntu machine. * Uncompress the gem file, uncompress the metadata file, edit the metadata file to use Ubuntu format, recompress metadatafile, recompress gem file. Hardcoding the date format in the gemspec file to the Ubuntu version does not help. The date is redone when the gem is built. ---------------------------------------------------------------------- Comment By: Alex Chaffee (alexch) Date: 2011-05-18 15:59 Message: Looks like a dup of bug #29181. FWIW it's not Ubuntu vs MacOS, it looks like it's Ruby 1.9.2p180 vs Ruby 1.9.2p0 (or thereabouts). Can you do a "ruby -v" on each of your boxes to confirm my hypothesis? http://rubyforge.org/tracker/index.php?func=detail&aid=29181&group_id=126&atid=575 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29202&group_id=126 From noreply at rubyforge.org Wed May 18 19:38:59 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 18 May 2011 19:38:59 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29181 ] RubyGems date spec field causing issues Message-ID: <20110518233859.19DFE185838A@rubyforge.org> Bugs item #29181, was opened at 2011-05-07 06:42 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29181&group_id=126 Category: other Group: None Status: Open Resolution: None Priority: 5 Submitted By: Luis Lavena (luislavena) Assigned to: Ryan Davis (zenspider) Summary: RubyGems date spec field causing issues Initial Comment: A new gem just released by one of the RubyInstaller contributors generated this: http://groups.google.com/group/rubyinstaller/msg/6a0b05d51811f5bc A simple gem, generated with Ruby 1.9.2 causes date to be generated incorrectly: Ruby 1.9.2 with RubyGems 1.8.1 date: 2011-05-07 00:00:00.000000000Z Ruby 1.8.7 with RubyGems 1.8.1: date: 2011-05-07 00:00:00 Z Installing that gem causes this: Invalid gemspec in [C:/Users/Luis/.gem/ruby/x86-mingw32/1.8/specifications/autotest-snarl-0.0.2.gemspec]: invalid date format in specification: "2011-05-07 00:00:00.000000000Z" C:/Users/Luis/Tools/ruby/ruby-1.8.7-p334-i386-mingw32/lib/ruby/site_ruby/1.8/rubygems/specification.rb:277:in `_resort!': undefined method `name' for nil:NilClass (NoMethodError) Not during installation but later in the process. You can reproduce this using my simple gem here: https://github.com/luislavena/autotest-snarl I don't use anything that is not RubyGems and Rake to generate it (even use Gem::PackageTask) ---------------------------------------------------------------------- Comment By: Alex Chaffee (alexch) Date: 2011-05-18 16:38 Message: Looks like this might fix it: specification:974 Change if /\A(\d{4})-(\d{2})-(\d{2})\Z/ =~ date then to if /\A(\d{4})-(\d{2})-(\d{2})\b/ =~ date then (unit test notwithstanding, of course...) Unfortunately it won't change it for earlier versions of Rubygems. For that it'd be necessary to change the output... maybe a quick hack like running gsub on the yaml output from builder.rb would suffice. ---------------------------------------------------------------------- Comment By: Alex Chaffee (alexch) Date: 2011-05-18 15:57 Message: Confirmed: Building the gem with 1.9.2p180 makes a metadata field with a different date format than building the gem with 1.9.2p0. And that new format is unreadable by older versions of Ruby. I think it's that they added fractional seconds to the time, and the poor old date parser breaks when it hits ".0000000". It looks like Gem is just using "to_yaml" to turn the spec into the metadata file (builder.rb:79), so this isn't something that can be fixed with a simple strftime format tweak. See also bug #29202 ---------------------------------------------------------------------- Comment By: Alex Chaffee (alexch) Date: 2011-05-18 15:25 Message: Verified on Ruby 1.9.2p180. This seems to have happened sometime between 1.9.2-p0 and 1.9.2-p180, but I haven't yet done the regression to confirm. I know 1.8.7 works OK. To summarize: using MRI 1.9.2p180 to generate a gem results in an invalid date format. Workaround: use an older version or Ruby when *building* the gem. And do "gem specification pkg/foo-1.2.3.gem | grep date" to verify that your date is in the proper format before pushing to gemcutter. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29181&group_id=126 From noreply at rubyforge.org Wed May 18 19:49:52 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 18 May 2011 19:49:52 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29202 ] gem build should force standard date format in metadata file Message-ID: <20110518234952.EA969185838A@rubyforge.org> Bugs item #29202, was opened at 2011-05-13 17:42 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29202&group_id=126 Category: `gem` commands (other) Group: None Status: Open Resolution: None Priority: 3 Submitted By: Mike Bethany (mikbe) Assigned to: Nobody (None) Summary: gem build should force standard date format in metadata file Initial Comment: **Description:** When building a gem the date format used on my OS X machines is incompatible with the date format used on my Ubuntu 10.10 virtual machines. OS X uses the following format: date: 2011-05-13 00:00:00.000000000Z Where as on Ubuntu the date format is: date: 2011-05-13 00:00:00 Z **Error message on Ubuntu (but not OS X):** Invalid gemspec in [/usr/local/ruby/lib/ruby/gems/1.9.1/specifications/osx_vs_ubuntu-0.0.1.gemspec]: invalid date format in specification: "2011-05-13 00:00:00.000000000Z" /usr/local/ruby/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:277:in `block in _resort!': undefined method `name' for nil:NilClass (NoMethodError) from /usr/local/ruby/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:276:in `sort!' from /usr/local/ruby/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:276:in `_resort!' from /usr/local/ruby/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:270:in `_all' from /usr/local/ruby/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:402:in `each' from /usr/local/ruby/lib/ruby/site_ruby/1.9.1/rubygems/dependency.rb:216:in `find_all' from /usr/local/ruby/lib/ruby/site_ruby/1.9.1/rubygems/dependency.rb:216:in `matching_specs' from /usr/local/ruby/lib/ruby/site_ruby/1.9.1/rubygems/dependency.rb:238:in `to_specs' from /usr/local/ruby/lib/ruby/site_ruby/1.9.1/rubygems/dependency.rb:256:in `to_spec' from /usr/local/ruby/lib/ruby/site_ruby/1.9.1/rubygems.rb:1182:in `gem' from /usr/local/ruby/bin/rake:18:in `
' **Steps to replicate:** Create a gem app: $ bundler gem osx_vs_ubuntu $ cd osx_vs_ubuntu $ git add . $ git commit -am "initial commit" Edit gemspec file setting: authors, email, summary, and description. Build the app on OS X machine: $ rake build Copy gem to an Ubuntu machine. Install gem on Ubuntu machine. $ gem install osx_vs_ubuntu-0.0.1.gem Invalid gemspec in [/usr/local/ruby/lib/ruby/gems/1.9.1/specifications/osx_vs_ubuntu-0.0.1.gemspec]: invalid date format in specification: "2011-05-13 00:00:00.000000000Z" ERROR: While executing gem ... (NoMethodError) undefined method `name' for nil:NilClass **Work arounds** * Build the gem on an Ubuntu machine. * Uncompress the gem file, uncompress the metadata file, edit the metadata file to use Ubuntu format, recompress metadatafile, recompress gem file. Hardcoding the date format in the gemspec file to the Ubuntu version does not help. The date is redone when the gem is built. ---------------------------------------------------------------------- >Comment By: Mike Bethany (mikbe) Date: 2011-05-18 19:49 Message: It doesn't appear to be a Ruby 1.9.2p180 vs p0 issue: Ubuntu 11.04 (GNU/Linux 2.6.38-8-server x86_64): $ ruby -v ruby 1.9.2p180 (2011-02-18 revision 30909) [x86_64-linux] OS X 10.6.7 (Darwin Kernel Version 10.7.0): $ ruby -v ruby 1.9.2p180 (2011-02-18 revision 30909) [x86_64-darwin10.7.0] ---------------------------------------------------------------------- Comment By: Alex Chaffee (alexch) Date: 2011-05-18 18:59 Message: Looks like a dup of bug #29181. FWIW it's not Ubuntu vs MacOS, it looks like it's Ruby 1.9.2p180 vs Ruby 1.9.2p0 (or thereabouts). Can you do a "ruby -v" on each of your boxes to confirm my hypothesis? http://rubyforge.org/tracker/index.php?func=detail&aid=29181&group_id=126&atid=575 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29202&group_id=126 From noreply at rubyforge.org Wed May 18 20:35:48 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 18 May 2011 20:35:48 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29181 ] RubyGems date spec field causing issues Message-ID: <20110519003548.D40AE18583A2@rubyforge.org> Bugs item #29181, was opened at 2011-05-07 06:42 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29181&group_id=126 Category: other Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Luis Lavena (luislavena) Assigned to: Ryan Davis (zenspider) Summary: RubyGems date spec field causing issues Initial Comment: A new gem just released by one of the RubyInstaller contributors generated this: http://groups.google.com/group/rubyinstaller/msg/6a0b05d51811f5bc A simple gem, generated with Ruby 1.9.2 causes date to be generated incorrectly: Ruby 1.9.2 with RubyGems 1.8.1 date: 2011-05-07 00:00:00.000000000Z Ruby 1.8.7 with RubyGems 1.8.1: date: 2011-05-07 00:00:00 Z Installing that gem causes this: Invalid gemspec in [C:/Users/Luis/.gem/ruby/x86-mingw32/1.8/specifications/autotest-snarl-0.0.2.gemspec]: invalid date format in specification: "2011-05-07 00:00:00.000000000Z" C:/Users/Luis/Tools/ruby/ruby-1.8.7-p334-i386-mingw32/lib/ruby/site_ruby/1.8/rubygems/specification.rb:277:in `_resort!': undefined method `name' for nil:NilClass (NoMethodError) Not during installation but later in the process. You can reproduce this using my simple gem here: https://github.com/luislavena/autotest-snarl I don't use anything that is not RubyGems and Rake to generate it (even use Gem::PackageTask) ---------------------------------------------------------------------- >Comment By: Ryan Davis (zenspider) Date: 2011-05-18 17:35 Message: It isn't the fractional seconds as everyone thinks... it is the lack of a space before the "Z". Psych has been "fixed" and made into a gem to address this on the YAML side, and I've got a patch to normalize_yaml_input to address things on the loading side. ---------------------------------------------------------------------- Comment By: Alex Chaffee (alexch) Date: 2011-05-18 16:38 Message: Looks like this might fix it: specification:974 Change if /\A(\d{4})-(\d{2})-(\d{2})\Z/ =~ date then to if /\A(\d{4})-(\d{2})-(\d{2})\b/ =~ date then (unit test notwithstanding, of course...) Unfortunately it won't change it for earlier versions of Rubygems. For that it'd be necessary to change the output... maybe a quick hack like running gsub on the yaml output from builder.rb would suffice. ---------------------------------------------------------------------- Comment By: Alex Chaffee (alexch) Date: 2011-05-18 15:57 Message: Confirmed: Building the gem with 1.9.2p180 makes a metadata field with a different date format than building the gem with 1.9.2p0. And that new format is unreadable by older versions of Ruby. I think it's that they added fractional seconds to the time, and the poor old date parser breaks when it hits ".0000000". It looks like Gem is just using "to_yaml" to turn the spec into the metadata file (builder.rb:79), so this isn't something that can be fixed with a simple strftime format tweak. See also bug #29202 ---------------------------------------------------------------------- Comment By: Alex Chaffee (alexch) Date: 2011-05-18 15:25 Message: Verified on Ruby 1.9.2p180. This seems to have happened sometime between 1.9.2-p0 and 1.9.2-p180, but I haven't yet done the regression to confirm. I know 1.8.7 works OK. To summarize: using MRI 1.9.2p180 to generate a gem results in an invalid date format. Workaround: use an older version or Ruby when *building* the gem. And do "gem specification pkg/foo-1.2.3.gem | grep date" to verify that your date is in the proper format before pushing to gemcutter. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29181&group_id=126 From noreply at rubyforge.org Wed May 18 20:57:12 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 18 May 2011 20:57:12 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29202 ] gem build should force standard date format in metadata file Message-ID: <20110519005712.9AE2B18583A2@rubyforge.org> Bugs item #29202, was opened at 2011-05-13 14:42 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29202&group_id=126 Category: `gem` commands (other) Group: None >Status: Closed >Resolution: Rejected Priority: 3 Submitted By: Mike Bethany (mikbe) >Assigned to: Ryan Davis (zenspider) Summary: gem build should force standard date format in metadata file Initial Comment: **Description:** When building a gem the date format used on my OS X machines is incompatible with the date format used on my Ubuntu 10.10 virtual machines. OS X uses the following format: date: 2011-05-13 00:00:00.000000000Z Where as on Ubuntu the date format is: date: 2011-05-13 00:00:00 Z **Error message on Ubuntu (but not OS X):** Invalid gemspec in [/usr/local/ruby/lib/ruby/gems/1.9.1/specifications/osx_vs_ubuntu-0.0.1.gemspec]: invalid date format in specification: "2011-05-13 00:00:00.000000000Z" /usr/local/ruby/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:277:in `block in _resort!': undefined method `name' for nil:NilClass (NoMethodError) from /usr/local/ruby/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:276:in `sort!' from /usr/local/ruby/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:276:in `_resort!' from /usr/local/ruby/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:270:in `_all' from /usr/local/ruby/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:402:in `each' from /usr/local/ruby/lib/ruby/site_ruby/1.9.1/rubygems/dependency.rb:216:in `find_all' from /usr/local/ruby/lib/ruby/site_ruby/1.9.1/rubygems/dependency.rb:216:in `matching_specs' from /usr/local/ruby/lib/ruby/site_ruby/1.9.1/rubygems/dependency.rb:238:in `to_specs' from /usr/local/ruby/lib/ruby/site_ruby/1.9.1/rubygems/dependency.rb:256:in `to_spec' from /usr/local/ruby/lib/ruby/site_ruby/1.9.1/rubygems.rb:1182:in `gem' from /usr/local/ruby/bin/rake:18:in `
' **Steps to replicate:** Create a gem app: $ bundler gem osx_vs_ubuntu $ cd osx_vs_ubuntu $ git add . $ git commit -am "initial commit" Edit gemspec file setting: authors, email, summary, and description. Build the app on OS X machine: $ rake build Copy gem to an Ubuntu machine. Install gem on Ubuntu machine. $ gem install osx_vs_ubuntu-0.0.1.gem Invalid gemspec in [/usr/local/ruby/lib/ruby/gems/1.9.1/specifications/osx_vs_ubuntu-0.0.1.gemspec]: invalid date format in specification: "2011-05-13 00:00:00.000000000Z" ERROR: While executing gem ... (NoMethodError) undefined method `name' for nil:NilClass **Work arounds** * Build the gem on an Ubuntu machine. * Uncompress the gem file, uncompress the metadata file, edit the metadata file to use Ubuntu format, recompress metadatafile, recompress gem file. Hardcoding the date format in the gemspec file to the Ubuntu version does not help. The date is redone when the gem is built. ---------------------------------------------------------------------- >Comment By: Ryan Davis (zenspider) Date: 2011-05-18 17:57 Message: This is a dupe and has nothing to do with OSX vs Ubuntu. This was discussed with the OP at length on reddit, but apparently was ignored. The problem is syck vs psych. Psych will output perfectly good (according to YAML spec) time strings that Syck can't parse. The problem is the missing space before the "Z". I assume that the OP doesn't have libyaml installed on ubuntu, so syck is used instead of psych. ---------------------------------------------------------------------- Comment By: Mike Bethany (mikbe) Date: 2011-05-18 16:49 Message: It doesn't appear to be a Ruby 1.9.2p180 vs p0 issue: Ubuntu 11.04 (GNU/Linux 2.6.38-8-server x86_64): $ ruby -v ruby 1.9.2p180 (2011-02-18 revision 30909) [x86_64-linux] OS X 10.6.7 (Darwin Kernel Version 10.7.0): $ ruby -v ruby 1.9.2p180 (2011-02-18 revision 30909) [x86_64-darwin10.7.0] ---------------------------------------------------------------------- Comment By: Alex Chaffee (alexch) Date: 2011-05-18 15:59 Message: Looks like a dup of bug #29181. FWIW it's not Ubuntu vs MacOS, it looks like it's Ruby 1.9.2p180 vs Ruby 1.9.2p0 (or thereabouts). Can you do a "ruby -v" on each of your boxes to confirm my hypothesis? http://rubyforge.org/tracker/index.php?func=detail&aid=29181&group_id=126&atid=575 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29202&group_id=126 From noreply at rubyforge.org Wed May 18 22:07:00 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 18 May 2011 22:07:00 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29202 ] gem build should force standard date format in metadata file Message-ID: <20110519020701.18E5A1858300@rubyforge.org> Bugs item #29202, was opened at 2011-05-13 17:42 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29202&group_id=126 Category: `gem` commands (other) Group: None Status: Closed Resolution: Rejected Priority: 3 Submitted By: Mike Bethany (mikbe) Assigned to: Ryan Davis (zenspider) Summary: gem build should force standard date format in metadata file Initial Comment: **Description:** When building a gem the date format used on my OS X machines is incompatible with the date format used on my Ubuntu 10.10 virtual machines. OS X uses the following format: date: 2011-05-13 00:00:00.000000000Z Where as on Ubuntu the date format is: date: 2011-05-13 00:00:00 Z **Error message on Ubuntu (but not OS X):** Invalid gemspec in [/usr/local/ruby/lib/ruby/gems/1.9.1/specifications/osx_vs_ubuntu-0.0.1.gemspec]: invalid date format in specification: "2011-05-13 00:00:00.000000000Z" /usr/local/ruby/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:277:in `block in _resort!': undefined method `name' for nil:NilClass (NoMethodError) from /usr/local/ruby/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:276:in `sort!' from /usr/local/ruby/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:276:in `_resort!' from /usr/local/ruby/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:270:in `_all' from /usr/local/ruby/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:402:in `each' from /usr/local/ruby/lib/ruby/site_ruby/1.9.1/rubygems/dependency.rb:216:in `find_all' from /usr/local/ruby/lib/ruby/site_ruby/1.9.1/rubygems/dependency.rb:216:in `matching_specs' from /usr/local/ruby/lib/ruby/site_ruby/1.9.1/rubygems/dependency.rb:238:in `to_specs' from /usr/local/ruby/lib/ruby/site_ruby/1.9.1/rubygems/dependency.rb:256:in `to_spec' from /usr/local/ruby/lib/ruby/site_ruby/1.9.1/rubygems.rb:1182:in `gem' from /usr/local/ruby/bin/rake:18:in `
' **Steps to replicate:** Create a gem app: $ bundler gem osx_vs_ubuntu $ cd osx_vs_ubuntu $ git add . $ git commit -am "initial commit" Edit gemspec file setting: authors, email, summary, and description. Build the app on OS X machine: $ rake build Copy gem to an Ubuntu machine. Install gem on Ubuntu machine. $ gem install osx_vs_ubuntu-0.0.1.gem Invalid gemspec in [/usr/local/ruby/lib/ruby/gems/1.9.1/specifications/osx_vs_ubuntu-0.0.1.gemspec]: invalid date format in specification: "2011-05-13 00:00:00.000000000Z" ERROR: While executing gem ... (NoMethodError) undefined method `name' for nil:NilClass **Work arounds** * Build the gem on an Ubuntu machine. * Uncompress the gem file, uncompress the metadata file, edit the metadata file to use Ubuntu format, recompress metadatafile, recompress gem file. Hardcoding the date format in the gemspec file to the Ubuntu version does not help. The date is redone when the gem is built. ---------------------------------------------------------------------- >Comment By: Mike Bethany (mikbe) Date: 2011-05-18 22:07 Message: The reason I say Ubuntu is because I'm being specific. I am telling you what operating system I'm having the problem with as piece of data not as a indication of the cause. I do have YAML installed in Ubuntu: ii libyaml-0-2 0.1.3-1 Fast YAML 1.1 parser and emitter library ii libyaml-dev 0.1.3-1 Fast YAML 1.1 parser and emitter library (development) And finally this was not discussed at length on reddit. This is the entirety of the time issue response, "This has nothing to do with ubuntu vs osx and everything to do with syck vs psych. You probably have the library you need on ubuntu and not on osx." Which was less than helpful. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-05-18 20:57 Message: This is a dupe and has nothing to do with OSX vs Ubuntu. This was discussed with the OP at length on reddit, but apparently was ignored. The problem is syck vs psych. Psych will output perfectly good (according to YAML spec) time strings that Syck can't parse. The problem is the missing space before the "Z". I assume that the OP doesn't have libyaml installed on ubuntu, so syck is used instead of psych. ---------------------------------------------------------------------- Comment By: Mike Bethany (mikbe) Date: 2011-05-18 19:49 Message: It doesn't appear to be a Ruby 1.9.2p180 vs p0 issue: Ubuntu 11.04 (GNU/Linux 2.6.38-8-server x86_64): $ ruby -v ruby 1.9.2p180 (2011-02-18 revision 30909) [x86_64-linux] OS X 10.6.7 (Darwin Kernel Version 10.7.0): $ ruby -v ruby 1.9.2p180 (2011-02-18 revision 30909) [x86_64-darwin10.7.0] ---------------------------------------------------------------------- Comment By: Alex Chaffee (alexch) Date: 2011-05-18 18:59 Message: Looks like a dup of bug #29181. FWIW it's not Ubuntu vs MacOS, it looks like it's Ruby 1.9.2p180 vs Ruby 1.9.2p0 (or thereabouts). Can you do a "ruby -v" on each of your boxes to confirm my hypothesis? http://rubyforge.org/tracker/index.php?func=detail&aid=29181&group_id=126&atid=575 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29202&group_id=126 From noreply at rubyforge.org Thu May 19 13:29:14 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 19 May 2011 13:29:14 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29181 ] RubyGems date spec field causing issues Message-ID: <20110519172914.2754C18583A8@rubyforge.org> Bugs item #29181, was opened at 2011-05-07 06:42 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29181&group_id=126 Category: other Group: None Status: Closed Resolution: Accepted Priority: 5 Submitted By: Luis Lavena (luislavena) Assigned to: Ryan Davis (zenspider) Summary: RubyGems date spec field causing issues Initial Comment: A new gem just released by one of the RubyInstaller contributors generated this: http://groups.google.com/group/rubyinstaller/msg/6a0b05d51811f5bc A simple gem, generated with Ruby 1.9.2 causes date to be generated incorrectly: Ruby 1.9.2 with RubyGems 1.8.1 date: 2011-05-07 00:00:00.000000000Z Ruby 1.8.7 with RubyGems 1.8.1: date: 2011-05-07 00:00:00 Z Installing that gem causes this: Invalid gemspec in [C:/Users/Luis/.gem/ruby/x86-mingw32/1.8/specifications/autotest-snarl-0.0.2.gemspec]: invalid date format in specification: "2011-05-07 00:00:00.000000000Z" C:/Users/Luis/Tools/ruby/ruby-1.8.7-p334-i386-mingw32/lib/ruby/site_ruby/1.8/rubygems/specification.rb:277:in `_resort!': undefined method `name' for nil:NilClass (NoMethodError) Not during installation but later in the process. You can reproduce this using my simple gem here: https://github.com/luislavena/autotest-snarl I don't use anything that is not RubyGems and Rake to generate it (even use Gem::PackageTask) ---------------------------------------------------------------------- Comment By: Alex Chaffee (alexch) Date: 2011-05-19 10:29 Message: Aha! That explains it. Thanks. I recently upgraded from 1.9.2-p0 to 1.9.2-p180 and when I did, I didn't pass in any options to "rvm install". So it must not have found libyaml, and therefore my 1.9.2 was using syck instead of psych, where my 1.8.7 was using psych and thus could read the time ok. New workaround: (re)install Ruby like this: rvm package install readline sudo port install libyaml rvm install 1.9.2 -C "--with-libyaml-dir=/opt/local --with-readline-dir=$HOME/.rvm/usr" See also http://stackoverflow.com/questions/3190737/error-installing-ruby-1-8-6-and-openssl-using-rvm-under-snow-leopard/3262368#3262368 (where apparently I solved this problem a year ago and then ignored my own instructions) ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-05-18 17:35 Message: It isn't the fractional seconds as everyone thinks... it is the lack of a space before the "Z". Psych has been "fixed" and made into a gem to address this on the YAML side, and I've got a patch to normalize_yaml_input to address things on the loading side. ---------------------------------------------------------------------- Comment By: Alex Chaffee (alexch) Date: 2011-05-18 16:38 Message: Looks like this might fix it: specification:974 Change if /\A(\d{4})-(\d{2})-(\d{2})\Z/ =~ date then to if /\A(\d{4})-(\d{2})-(\d{2})\b/ =~ date then (unit test notwithstanding, of course...) Unfortunately it won't change it for earlier versions of Rubygems. For that it'd be necessary to change the output... maybe a quick hack like running gsub on the yaml output from builder.rb would suffice. ---------------------------------------------------------------------- Comment By: Alex Chaffee (alexch) Date: 2011-05-18 15:57 Message: Confirmed: Building the gem with 1.9.2p180 makes a metadata field with a different date format than building the gem with 1.9.2p0. And that new format is unreadable by older versions of Ruby. I think it's that they added fractional seconds to the time, and the poor old date parser breaks when it hits ".0000000". It looks like Gem is just using "to_yaml" to turn the spec into the metadata file (builder.rb:79), so this isn't something that can be fixed with a simple strftime format tweak. See also bug #29202 ---------------------------------------------------------------------- Comment By: Alex Chaffee (alexch) Date: 2011-05-18 15:25 Message: Verified on Ruby 1.9.2p180. This seems to have happened sometime between 1.9.2-p0 and 1.9.2-p180, but I haven't yet done the regression to confirm. I know 1.8.7 works OK. To summarize: using MRI 1.9.2p180 to generate a gem results in an invalid date format. Workaround: use an older version or Ruby when *building* the gem. And do "gem specification pkg/foo-1.2.3.gem | grep date" to verify that your date is in the proper format before pushing to gemcutter. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29181&group_id=126 From noreply at rubyforge.org Thu May 19 17:42:23 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 19 May 2011 17:42:23 -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: <20110519214224.0D8061858376@rubyforge.org> Bugs item #29216, was opened at 2011-05-19 14: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: Open Resolution: None Priority: 3 Submitted By: David Kellum (dekellum) Assigned to: Nobody (None) 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... ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29216&group_id=126 From ryand-ruby at zenspider.com Thu May 19 17:38:44 2011 From: ryand-ruby at zenspider.com (Ryan Davis) Date: Thu, 19 May 2011 14:38:44 -0700 Subject: [Rubygems-developers] ANN] isolate 3.1.0 Released Message-ID: <5D5AF172-9E18-407F-B3E7-949E270A9887@zenspider.com> isolate version 3.1.0 has been released! * Isolate is a very simple RubyGems sandbox. It provides a way to express and automatically install your project's Gem dependencies. Changes: ### 3.1.0 / 2011-05-19 * 4 minor enhancements: * Added ZenTest as a development dependency so rake multi works in isolation. * Added rake task git:freshen to forcefully remove stale gems. * Extracted remove from cleanup method so rake tasks can use remove. * Switched to minitest plugin in hoe spec * 6 bug fixes: * Fixed 1.9.x warnings * Fixed a test broken only in isolation from hoe itself. * Fixed an enumeration bug caused by my not running `rake multi` sooner. (Eric Wong) * Fixed requirements in readme. * Hoe plugin now properly adds development dependencies. * Hoe plugin now properly uses (and possibly defines) the Isolate.sandbox. From drbrain at segment7.net Thu May 19 20:44:08 2011 From: drbrain at segment7.net (Eric Hodel) Date: Thu, 19 May 2011 17:44:08 -0700 Subject: [Rubygems-developers] [ANN] rubygems-update 1.8.3 Released Message-ID: <8F3AEF93-F7E8-4C6B-918D-14503EB58FA9@segment7.net> rubygems-update version 1.8.3 has been released! * http://rubygems.org * http://docs.rubygems.org * http://help.rubygems.org * http://github.com/rubygems * http://rubyforge.org/projects/rubygems RubyGems is a package management framework for Ruby. This gem is an update for the RubyGems software. You must have an installation of RubyGems before this update can be applied. See Gem for information on RubyGems (or `ri Gem`) To upgrade to the latest RubyGems, run: $ gem update --system # you might need to be an administrator or root See UPGRADING.rdoc for more details and alternative instructions. ----- If you don't have RubyGems installed, your can still do it manually: * Download from: https://rubygems.org/pages/download * Unpack into a directory and cd there * Install with: ruby setup.rb # you may need admin/root privilege For more details and other options, see: ruby setup.rb --help Changes: === 1.8.3 / 2011-05-19 After installing RubyGems 1.8.0 you will see deprecations when loading your exsting gems. Run `gem pristine --all --no-extensions` to regenerate your gem specifications safely. Currently RubyGems does not save the build arguments used to build gems with extensions. You will need to run `gem pristine gem_with_extension -- --build-arg` to regenerate a gem with an extension where it requires special build arguments. * 4 bug fixes: * Fix independent testing of test_gem_package_tar_output. Ruby Bug #4686 by Shota Fukumori * Fix test failures for systems with separate ruby versions. Ruby Bug #3808 by Jeremy Evans * Fixed some bad calls left behind after rolling out some refactorings. * Syck has a parse error on (good) times output from Psych. (dazuma, et al) From noreply at rubyforge.org Fri May 20 10:21:07 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 20 May 2011 10:21:07 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29188 ] rails 2.3.11 fails to load with rubygems 1.8.1 Message-ID: <20110520142107.54002185836B@rubyforge.org> Bugs item #29188, was opened at 2011-05-08 21:33 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29188&group_id=126 Category: other Group: None Status: Open Resolution: Rejected Priority: 3 Submitted By: Greg Hazel (ghazel) Assigned to: Ryan Davis (zenspider) Summary: rails 2.3.11 fails to load with rubygems 1.8.1 Initial Comment: Upgraded from 1.7.2 to 1.8.1, then a Rails 2.3.11 app failed to load: /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/gems/1.8/gems/rails-2.3.11/lib/rails/gem_dependency.rb:277:in `==': undefined method `name' for "POpen4":String (NoMethodError) from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/site_ruby/1.8/rubygems/dependency.rb:217:in `===' from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/site_ruby/1.8/rubygems/dependency.rb:217:in `matching_specs' from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/site_ruby/1.8/rubygems/specification.rb:539:in `find_all' from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/site_ruby/1.8/rubygems/specification.rb:403:in `each' from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/site_ruby/1.8/rubygems/specification.rb:402:in `each' from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/site_ruby/1.8/rubygems/dependency.rb:216:in `find_all' from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/site_ruby/1.8/rubygems/dependency.rb:216:in `matching_specs' from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/site_ruby/1.8/rubygems/dependency.rb:238:in `to_specs' from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/site_ruby/1.8/rubygems/dependency.rb:256:in `to_spec' from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/site_ruby/1.8/rubygems.rb:1182:in `gem' from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/gems/1.8/gems/rails-2.3.11/lib/rails/gem_dependency.rb:75:in `add_load_paths' from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/gems/1.8/gems/rails-2.3.11/lib/initializer.rb:301:in `add_gem_load_paths' from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/gems/1.8/gems/rails-2.3.11/lib/initializer.rb:301:in `each' from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/gems/1.8/gems/rails-2.3.11/lib/initializer.rb:301:in `add_gem_load_paths' from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/gems/1.8/gems/rails-2.3.11/lib/initializer.rb:132:in `process' from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/gems/1.8/gems/rails-2.3.11/lib/initializer.rb:113:in `send' from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/gems/1.8/gems/rails-2.3.11/lib/initializer.rb:113:in `run' ---------------------------------------------------------------------- Comment By: etienne massip (emassip) Date: 2011-05-20 16:21 Message: Got same issue in Redmine with Rails 2.3.11 and latests RubyGems versions, see http://www.redmine.org/issues/8325. ---------------------------------------------------------------------- Comment By: Roger Pack (rogerdpack) Date: 2011-05-13 23:01 Message: Just ran into this, too. http://betterlogic.com/roger/2011/05/undefined-method/ ---------------------------------------------------------------------- Comment By: Greg Hazel (ghazel) Date: 2011-05-12 18:23 Message: The first Rubygems commit where this error is reproducible is: https://github.com/rubygems/rubygems/commit/97932d63efbd35704c1669ea281a4701fe2ecb60 Although before that a different error is encountered, which started with this commit: https://github.com/rubygems/rubygems/commit/78a43480440f527c22452e1ae986206712959ef5 ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-05-12 05:32 Message: Cleaned up path that works in my rubygems checkout: rails-2.3.11/lib/rails/gem_dependency.rb:277:in `==': undefined method `name' for "POpen4":String (NoMethodError) from lib/rubygems/dependency.rb:217:in `===' from lib/rubygems/dependency.rb:217:in `matching_specs' from lib/rubygems/specification.rb:539:in `find_all' from lib/rubygems/specification.rb:403:in `each' from lib/rubygems/specification.rb:402:in `each' from lib/rubygems/dependency.rb:216:in `find_all' from lib/rubygems/dependency.rb:216:in `matching_specs' from lib/rubygems/dependency.rb:238:in `to_specs' from lib/rubygems/dependency.rb:256:in `to_spec' from lib/rubygems.rb:1182:in `gem' from rails-2.3.11/lib/rails/gem_dependency.rb:75:in `add_load_paths' from rails-2.3.11/lib/initializer.rb:301:in `add_gem_load_paths' from rails-2.3.11/lib/initializer.rb:301:in `each' from rails-2.3.11/lib/initializer.rb:301:in `add_gem_load_paths' from rails-2.3.11/lib/initializer.rb:132:in `process' from rails-2.3.11/lib/initializer.rb:113:in `send' from rails-2.3.11/lib/initializer.rb:113:in `run' gem_dependency.rb:277 is a buggy impl of #==: def ==(other) self.name == other.name && self.requirement == other.requirement end It's simply bad form to not check the class first. Not sure how that ever passed code review. That alone would probably fix the issue, but I'm not sure as I can't tell you why their call of #name returns another dep. Couple that with a very sketchy implementation: def add_load_paths self.class.add_frozen_gem_path return if @loaded || @load_paths_added if framework_gem? @load_paths_added = @loaded = @frozen = true return end gem self @spec = Gem.loaded_specs[name] @frozen = @spec.loaded_from.include?(self.class.unpacked_path) if @spec @load_paths_added = true rescue Gem::LoadError end `gem self` where self is a GemDependency (a subclass of our Gem::Dependency) just doesn't make sense. I'm not sure how this ever worked and it is possible it never did given that completely blithe rescue at the bottom... ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29188&group_id=126 From noreply at rubyforge.org Fri May 20 12:49:34 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 20 May 2011 12:49:34 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29217 ] RubyGems uses deprecated API: YAML.quick_emit Message-ID: <20110520164934.C505F1858376@rubyforge.org> Bugs item #29217, was opened at 2011-05-20 12:49 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29217&group_id=126 Category: other Group: None Status: Open Resolution: None Priority: 3 Submitted By: Scott Tadman (tadman) Assigned to: Nobody (None) Summary: RubyGems uses deprecated API: YAML.quick_emit Initial Comment: Running `rake test` on rubygems produces thousands of warnings about YAML.quick_emit being deprecated. This was fixed by Tenderlove with a patch associated with the ticket at http://redmine.ruby-lang.org/issues/show/4163 so it should be easy to repair. After examining the code it seems this warning may not be presented to people if they have warnings turned off, or if they're using a non-syck YAML engine so it may not have been observed by the build team. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29217&group_id=126 From noreply at rubyforge.org Fri May 20 14:53:24 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 20 May 2011 14:53:24 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29188 ] rails 2.3.11 fails to load with rubygems 1.8.1 Message-ID: <20110520185325.A9ED81858377@rubyforge.org> Bugs item #29188, was opened at 2011-05-08 21:33 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29188&group_id=126 Category: other Group: None Status: Open Resolution: Rejected Priority: 3 Submitted By: Greg Hazel (ghazel) Assigned to: Ryan Davis (zenspider) Summary: rails 2.3.11 fails to load with rubygems 1.8.1 Initial Comment: Upgraded from 1.7.2 to 1.8.1, then a Rails 2.3.11 app failed to load: /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/gems/1.8/gems/rails-2.3.11/lib/rails/gem_dependency.rb:277:in `==': undefined method `name' for "POpen4":String (NoMethodError) from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/site_ruby/1.8/rubygems/dependency.rb:217:in `===' from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/site_ruby/1.8/rubygems/dependency.rb:217:in `matching_specs' from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/site_ruby/1.8/rubygems/specification.rb:539:in `find_all' from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/site_ruby/1.8/rubygems/specification.rb:403:in `each' from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/site_ruby/1.8/rubygems/specification.rb:402:in `each' from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/site_ruby/1.8/rubygems/dependency.rb:216:in `find_all' from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/site_ruby/1.8/rubygems/dependency.rb:216:in `matching_specs' from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/site_ruby/1.8/rubygems/dependency.rb:238:in `to_specs' from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/site_ruby/1.8/rubygems/dependency.rb:256:in `to_spec' from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/site_ruby/1.8/rubygems.rb:1182:in `gem' from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/gems/1.8/gems/rails-2.3.11/lib/rails/gem_dependency.rb:75:in `add_load_paths' from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/gems/1.8/gems/rails-2.3.11/lib/initializer.rb:301:in `add_gem_load_paths' from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/gems/1.8/gems/rails-2.3.11/lib/initializer.rb:301:in `each' from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/gems/1.8/gems/rails-2.3.11/lib/initializer.rb:301:in `add_gem_load_paths' from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/gems/1.8/gems/rails-2.3.11/lib/initializer.rb:132:in `process' from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/gems/1.8/gems/rails-2.3.11/lib/initializer.rb:113:in `send' from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/gems/1.8/gems/rails-2.3.11/lib/initializer.rb:113:in `run' ---------------------------------------------------------------------- Comment By: etienne massip (emassip) Date: 2011-05-20 20:53 Message: BTW, looks like an Rails incompatibility issue. ---------------------------------------------------------------------- Comment By: etienne massip (emassip) Date: 2011-05-20 16:21 Message: Got same issue in Redmine with Rails 2.3.11 and latests RubyGems versions, see http://www.redmine.org/issues/8325. ---------------------------------------------------------------------- Comment By: Roger Pack (rogerdpack) Date: 2011-05-13 23:01 Message: Just ran into this, too. http://betterlogic.com/roger/2011/05/undefined-method/ ---------------------------------------------------------------------- Comment By: Greg Hazel (ghazel) Date: 2011-05-12 18:23 Message: The first Rubygems commit where this error is reproducible is: https://github.com/rubygems/rubygems/commit/97932d63efbd35704c1669ea281a4701fe2ecb60 Although before that a different error is encountered, which started with this commit: https://github.com/rubygems/rubygems/commit/78a43480440f527c22452e1ae986206712959ef5 ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-05-12 05:32 Message: Cleaned up path that works in my rubygems checkout: rails-2.3.11/lib/rails/gem_dependency.rb:277:in `==': undefined method `name' for "POpen4":String (NoMethodError) from lib/rubygems/dependency.rb:217:in `===' from lib/rubygems/dependency.rb:217:in `matching_specs' from lib/rubygems/specification.rb:539:in `find_all' from lib/rubygems/specification.rb:403:in `each' from lib/rubygems/specification.rb:402:in `each' from lib/rubygems/dependency.rb:216:in `find_all' from lib/rubygems/dependency.rb:216:in `matching_specs' from lib/rubygems/dependency.rb:238:in `to_specs' from lib/rubygems/dependency.rb:256:in `to_spec' from lib/rubygems.rb:1182:in `gem' from rails-2.3.11/lib/rails/gem_dependency.rb:75:in `add_load_paths' from rails-2.3.11/lib/initializer.rb:301:in `add_gem_load_paths' from rails-2.3.11/lib/initializer.rb:301:in `each' from rails-2.3.11/lib/initializer.rb:301:in `add_gem_load_paths' from rails-2.3.11/lib/initializer.rb:132:in `process' from rails-2.3.11/lib/initializer.rb:113:in `send' from rails-2.3.11/lib/initializer.rb:113:in `run' gem_dependency.rb:277 is a buggy impl of #==: def ==(other) self.name == other.name && self.requirement == other.requirement end It's simply bad form to not check the class first. Not sure how that ever passed code review. That alone would probably fix the issue, but I'm not sure as I can't tell you why their call of #name returns another dep. Couple that with a very sketchy implementation: def add_load_paths self.class.add_frozen_gem_path return if @loaded || @load_paths_added if framework_gem? @load_paths_added = @loaded = @frozen = true return end gem self @spec = Gem.loaded_specs[name] @frozen = @spec.loaded_from.include?(self.class.unpacked_path) if @spec @load_paths_added = true rescue Gem::LoadError end `gem self` where self is a GemDependency (a subclass of our Gem::Dependency) just doesn't make sense. I'm not sure how this ever worked and it is possible it never did given that completely blithe rescue at the bottom... ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29188&group_id=126 From noreply at rubyforge.org Sun May 22 04:05:02 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 22 May 2011 04:05:02 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Feature Requests-29220 ] Rubygems should follow RationalVersioningPolicy itself Message-ID: <20110522080502.D97901858300@rubyforge.org> Feature Requests item #29220, was opened at 2011-05-22 10:05 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=578&aid=29220&group_id=126 Category: other Group: future Status: Open Resolution: None Priority: 3 Submitted By: Beoran Aegul (beoran) Assigned to: Nobody (None) Summary: Rubygems should follow RationalVersioningPolicy itself Initial Comment: As per the title, I think rubygems should follow RationalVersioningPolicy or similar. I think it's a bit rough that many backwards-incompatible changes were introduced in a 1.x release. It's fine to get rid of old cruft, and break backwards compatibility if needed, but do so in a 2.x release, not a 1.xxx, please. Kind Regards, B. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=578&aid=29220&group_id=126 From noreply at rubyforge.org Sun May 22 04:10:40 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 22 May 2011 04:10:40 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29176 ] Scary warnings are scaring helpless developers who can't do a thing about it Message-ID: <20110522081041.1D00D19783BC@rubyforge.org> Bugs item #29176, was opened at 2011-05-06 22: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: Beoran Aegul (beoran) Date: 2011-05-22 10: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 22: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 23: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 23: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 18: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 17: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 17: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 09: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-12 01: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 20: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 11: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-11 06: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-11 05: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-11 03: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 19: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 18: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 20: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 18: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 10:56 Message: No worries. ---------------------------------------------------------------------- Comment By: Justin Collins (presidentbeef) Date: 2011-05-08 08:57 Message: Sorry, my mistake. I didn't notice that gem was called out specifically. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-05-08 08: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-08 08: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-08 08: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-08 07: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-07 00: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 23: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 22: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 22: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 22: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 Sun May 22 17:06:01 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 22 May 2011 17:06:01 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29176 ] Scary warnings are scaring helpless developers who can't do a thing about it Message-ID: <20110522210601.AC8EE19783BC@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: 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 Sun May 22 19:38:29 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 22 May 2011 19:38:29 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29176 ] Scary warnings are scaring helpless developers who can't do a thing about it Message-ID: <20110522233829.9B2E618581B2@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-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 Mon May 23 11:20:43 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 23 May 2011 11:20:43 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29116 ] Mega slowness in custom require Message-ID: <20110523152043.B1D7D185838A@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-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 Mon May 23 19:47:40 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 23 May 2011 19:47:40 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29116 ] Mega slowness in custom require Message-ID: <20110523234740.7A5703C8041@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-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 Mon May 23 20:32:11 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 23 May 2011 20:32:11 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29116 ] Mega slowness in custom require Message-ID: <20110524003211.849EB3C8042@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-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 Mon May 23 20:33:28 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 23 May 2011 20:33:28 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29145 ] Dynamically generated GemSpec.files ends up empty Message-ID: <20110524003328.D32E518583B1@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. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29145&group_id=126 From noreply at rubyforge.org Mon May 23 20:38:18 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 23 May 2011 20:38:18 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29163 ] Invalid specs resulting from incorrect syck time parsing Message-ID: <20110524003818.BFC6018583B1@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: 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: 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 Mon May 23 20:43:36 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 23 May 2011 20:43:36 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29217 ] RubyGems uses deprecated API: YAML.quick_emit Message-ID: <20110524004337.7B58418581B2@rubyforge.org> Bugs item #29217, was opened at 2011-05-20 09:49 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29217&group_id=126 Category: other Group: None Status: Open Resolution: None Priority: 3 Submitted By: Scott Tadman (tadman) >Assigned to: Ryan Davis (zenspider) Summary: RubyGems uses deprecated API: YAML.quick_emit Initial Comment: Running `rake test` on rubygems produces thousands of warnings about YAML.quick_emit being deprecated. This was fixed by Tenderlove with a patch associated with the ticket at http://redmine.ruby-lang.org/issues/show/4163 so it should be easy to repair. After examining the code it seems this warning may not be presented to people if they have warnings turned off, or if they're using a non-syck YAML engine so it may not have been observed by the build team. ---------------------------------------------------------------------- >Comment By: Ryan Davis (zenspider) Date: 2011-05-23 17:43 Message: What version of ruby are you running? I'm not seeing this at all on either 1.8.7 or 1.9.2. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29217&group_id=126 From noreply at rubyforge.org Mon May 23 20:47:17 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 23 May 2011 20:47:17 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29145 ] Dynamically generated GemSpec.files ends up empty Message-ID: <20110524004717.5976818583AD@rubyforge.org> Bugs item #29145, was opened at 2011-04-23 08: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: Luis Lavena (luislavena) Date: 2011-05-23 21: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 Mon May 23 20:59:26 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 23 May 2011 20:59:26 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29217 ] RubyGems uses deprecated API: YAML.quick_emit Message-ID: <20110524005927.0D88E18583A9@rubyforge.org> Bugs item #29217, was opened at 2011-05-20 09:49 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29217&group_id=126 Category: other Group: None >Status: Closed >Resolution: Rejected Priority: 3 Submitted By: Scott Tadman (tadman) Assigned to: Ryan Davis (zenspider) Summary: RubyGems uses deprecated API: YAML.quick_emit Initial Comment: Running `rake test` on rubygems produces thousands of warnings about YAML.quick_emit being deprecated. This was fixed by Tenderlove with a patch associated with the ticket at http://redmine.ruby-lang.org/issues/show/4163 so it should be easy to repair. After examining the code it seems this warning may not be presented to people if they have warnings turned off, or if they're using a non-syck YAML engine so it may not have been observed by the build team. ---------------------------------------------------------------------- >Comment By: Ryan Davis (zenspider) Date: 2011-05-23 17:59 Message: ok... I've got a repro by forcing syck at the top of rubygems.rb and running the tests. I've consulted with tenderlove on this and the only "solution" is to install libyaml and switch to psych on 1.9. There is no other way to emit custom yaml on syck other than using deprecated API. Sorry. :/ ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-05-23 17:43 Message: What version of ruby are you running? I'm not seeing this at all on either 1.8.7 or 1.9.2. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29217&group_id=126 From noreply at rubyforge.org Tue May 24 05:43:23 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 24 May 2011 05:43:23 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29163 ] Invalid specs resulting from incorrect syck time parsing Message-ID: <20110524094324.E605D18583A4@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: 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: 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 Tue May 24 06:12:50 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 24 May 2011 06:12:50 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29163 ] Invalid specs resulting from incorrect syck time parsing Message-ID: <20110524101251.C2B3A18583A5@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: 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: 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 Tue May 24 06:20:57 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 24 May 2011 06:20:57 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29163 ] Invalid specs resulting from incorrect syck time parsing Message-ID: <20110524102057.D8DB718583A5@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: 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: 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 Tue May 24 14:02:12 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 24 May 2011 14:02:12 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29217 ] RubyGems uses deprecated API: YAML.quick_emit Message-ID: <20110524180213.0B06318583A2@rubyforge.org> Bugs item #29217, was opened at 2011-05-20 12:49 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29217&group_id=126 Category: other Group: None Status: Closed Resolution: Rejected Priority: 3 Submitted By: Scott Tadman (tadman) Assigned to: Ryan Davis (zenspider) Summary: RubyGems uses deprecated API: YAML.quick_emit Initial Comment: Running `rake test` on rubygems produces thousands of warnings about YAML.quick_emit being deprecated. This was fixed by Tenderlove with a patch associated with the ticket at http://redmine.ruby-lang.org/issues/show/4163 so it should be easy to repair. After examining the code it seems this warning may not be presented to people if they have warnings turned off, or if they're using a non-syck YAML engine so it may not have been observed by the build team. ---------------------------------------------------------------------- >Comment By: Scott Tadman (tadman) Date: 2011-05-24 14:02 Message: This is what I'm seeing running tests on 1.9.2. I don't have Psych installed. ........../Users/tadman/git/rubygems/lib/rubygems/specification.rb:1898:in `to_yaml': YAML.quick_emit is deprecated /Users/tadman/git/rubygems/lib/rubygems/specification.rb:1898:in `to_yaml': YAML.quick_emit is deprecated ./Users/tadman/git/rubygems/lib/rubygems/specification.rb:1898:in `to_yaml': YAML.quick_emit is deprecated ./Users/tadman/git/rubygems/lib/rubygems/specification.rb:1898:in `to_yaml': YAML.quick_emit is deprecated ../Users/tadman/git/rubygems/lib/rubygems/specification.rb:1898:in `to_yaml': YAML.quick_emit is deprecated /Users/tadman/git/rubygems/lib/rubygems/specification.rb:1898:in `to_yaml': YAML.quick_emit is deprecated ....../Users/tadman/git/rubygems/lib/rubygems/specification.rb:1898:in `to_yaml': YAML.quick_emit is deprecated /Users/tadman/git/rubygems/lib/rubygems/specification.rb:1898:in `to_yaml': YAML.quick_emit is deprecated ../Users/tadman/git/rubygems/lib/rubygems/specification.rb:1898:in `to_yaml': YAML.quick_emit is deprecated /Users/tadman/git/rubygems/lib/rubygems/specification.rb:1898:in `to_yaml': YAML.quick_emit is deprecated ....../Users/tadman/git/rubygems/lib/rubygems/specification.rb:1898:in `to_yaml': YAML.quick_emit is deprecated ./Users/tadman/git/rubygems/lib/rubygems/specification.rb:1898:in `to_yaml': YAML.quick_emit is deprecated .........../Users/tadman/git/rubygems/lib/rubygems/specification.rb:1898:in `to_yaml': YAML.quick_emit is deprecated /Users/tadman/git/rubygems/lib/rubygems/specification.rb:1898:in `to_yaml': YAML.quick_emit is deprecated /Users/tadman/git/rubygems/lib/rubygems/specification.rb:1898:in `to_yaml': YAML.quick_emit is deprecated /Users/tadman/git/rubygems/lib/rubygems/specification.rb:1898:in `to_yaml': YAML.quick_emit is deprecated /Users/tadman/git/rubygems/lib/rubygems/specification.rb:1898:in `to_yaml': YAML.quick_emit is deprecated /Users/tadman/git/rubygems/lib/rubygems/specification.rb:1898:in `to_yaml': YAML.quick_emit is deprecated /Users/tadman/git/rubygems/lib/rubygems/specification.rb:1898:in `to_yaml': YAML.quick_emit is deprecated /Users/tadman/git/rubygems/lib/rubygems/specification.rb:1898:in `to_yaml': YAML.quick_emit is deprecated /Users/tadman/git/rubygems/lib/rubygems/specification.rb:1898:in `to_yaml': YAML.quick_emit is deprecated It goes on like that for another few thousand lines. Output from irb: > YAML::ENGINE => # This triggers the quick_emit branch in Gem::Specification#to_yaml: def to_yaml(opts = {}) # :nodoc: if YAML.const_defined?(:ENGINE) && !YAML::ENGINE.syck? then super.gsub(/ !!null \n/, " \n") else YAML.quick_emit object_id, opts do |out| out.map taguri, to_yaml_style do |map| encode_with map end end end end Presumably if you have another YAML engine installed or loaded this will not trigger and you will not see the warnings. This branch should be exercised at least once during the tests. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-05-23 20:59 Message: ok... I've got a repro by forcing syck at the top of rubygems.rb and running the tests. I've consulted with tenderlove on this and the only "solution" is to install libyaml and switch to psych on 1.9. There is no other way to emit custom yaml on syck other than using deprecated API. Sorry. :/ ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-05-23 20:43 Message: What version of ruby are you running? I'm not seeing this at all on either 1.8.7 or 1.9.2. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29217&group_id=126 From noreply at rubyforge.org Tue May 24 14:31:53 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 24 May 2011 14:31:53 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29217 ] RubyGems uses deprecated API: YAML.quick_emit Message-ID: <20110524183153.CD1F418583A8@rubyforge.org> Bugs item #29217, was opened at 2011-05-20 09:49 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29217&group_id=126 Category: other Group: None Status: Closed Resolution: Rejected Priority: 3 Submitted By: Scott Tadman (tadman) Assigned to: Ryan Davis (zenspider) Summary: RubyGems uses deprecated API: YAML.quick_emit Initial Comment: Running `rake test` on rubygems produces thousands of warnings about YAML.quick_emit being deprecated. This was fixed by Tenderlove with a patch associated with the ticket at http://redmine.ruby-lang.org/issues/show/4163 so it should be easy to repair. After examining the code it seems this warning may not be presented to people if they have warnings turned off, or if they're using a non-syck YAML engine so it may not have been observed by the build team. ---------------------------------------------------------------------- >Comment By: Ryan Davis (zenspider) Date: 2011-05-24 11:31 Message: So, we're in agreement that this situation sucks. ;) I can't _reliably_ test both paths of to_yaml because I can't guarantee that the runtime will have both engines (like you). We do have some tests for to_yaml: 3924 % ack def.test_to_yaml test test/rubygems/test_gem_specification.rb 929: def test_to_yaml 939: def test_to_yaml_fancy 950: def test_to_yaml_platform_empty_string 956: def test_to_yaml_platform_legacy 968: def test_to_yaml_platform_nil but as you can see, none of them are engine specific. As I said before, this is an unfortunate situation, but valid. Syck is going away (it's not even the default engine in 1.9.3) and there is no workaround for this code _in_syck_, so the deprecation warning is valid. I talked tenderlove into improving the message to tell you to install libyaml and switch to psych (which means doing nothing on 1.9.3 and adding a require in ruby < 1.9.3--already done in rubygems). ---------------------------------------------------------------------- Comment By: Scott Tadman (tadman) Date: 2011-05-24 11:02 Message: This is what I'm seeing running tests on 1.9.2. I don't have Psych installed. ........../Users/tadman/git/rubygems/lib/rubygems/specification.rb:1898:in `to_yaml': YAML.quick_emit is deprecated /Users/tadman/git/rubygems/lib/rubygems/specification.rb:1898:in `to_yaml': YAML.quick_emit is deprecated ./Users/tadman/git/rubygems/lib/rubygems/specification.rb:1898:in `to_yaml': YAML.quick_emit is deprecated ./Users/tadman/git/rubygems/lib/rubygems/specification.rb:1898:in `to_yaml': YAML.quick_emit is deprecated ../Users/tadman/git/rubygems/lib/rubygems/specification.rb:1898:in `to_yaml': YAML.quick_emit is deprecated /Users/tadman/git/rubygems/lib/rubygems/specification.rb:1898:in `to_yaml': YAML.quick_emit is deprecated ....../Users/tadman/git/rubygems/lib/rubygems/specification.rb:1898:in `to_yaml': YAML.quick_emit is deprecated /Users/tadman/git/rubygems/lib/rubygems/specification.rb:1898:in `to_yaml': YAML.quick_emit is deprecated ../Users/tadman/git/rubygems/lib/rubygems/specification.rb:1898:in `to_yaml': YAML.quick_emit is deprecated /Users/tadman/git/rubygems/lib/rubygems/specification.rb:1898:in `to_yaml': YAML.quick_emit is deprecated ....../Users/tadman/git/rubygems/lib/rubygems/specification.rb:1898:in `to_yaml': YAML.quick_emit is deprecated ./Users/tadman/git/rubygems/lib/rubygems/specification.rb:1898:in `to_yaml': YAML.quick_emit is deprecated .........../Users/tadman/git/rubygems/lib/rubygems/specification.rb:1898:in `to_yaml': YAML.quick_emit is deprecated /Users/tadman/git/rubygems/lib/rubygems/specification.rb:1898:in `to_yaml': YAML.quick_emit is deprecated /Users/tadman/git/rubygems/lib/rubygems/specification.rb:1898:in `to_yaml': YAML.quick_emit is deprecated /Users/tadman/git/rubygems/lib/rubygems/specification.rb:1898:in `to_yaml': YAML.quick_emit is deprecated /Users/tadman/git/rubygems/lib/rubygems/specification.rb:1898:in `to_yaml': YAML.quick_emit is deprecated /Users/tadman/git/rubygems/lib/rubygems/specification.rb:1898:in `to_yaml': YAML.quick_emit is deprecated /Users/tadman/git/rubygems/lib/rubygems/specification.rb:1898:in `to_yaml': YAML.quick_emit is deprecated /Users/tadman/git/rubygems/lib/rubygems/specification.rb:1898:in `to_yaml': YAML.quick_emit is deprecated /Users/tadman/git/rubygems/lib/rubygems/specification.rb:1898:in `to_yaml': YAML.quick_emit is deprecated It goes on like that for another few thousand lines. Output from irb: > YAML::ENGINE => # This triggers the quick_emit branch in Gem::Specification#to_yaml: def to_yaml(opts = {}) # :nodoc: if YAML.const_defined?(:ENGINE) && !YAML::ENGINE.syck? then super.gsub(/ !!null \n/, " \n") else YAML.quick_emit object_id, opts do |out| out.map taguri, to_yaml_style do |map| encode_with map end end end end Presumably if you have another YAML engine installed or loaded this will not trigger and you will not see the warnings. This branch should be exercised at least once during the tests. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-05-23 17:59 Message: ok... I've got a repro by forcing syck at the top of rubygems.rb and running the tests. I've consulted with tenderlove on this and the only "solution" is to install libyaml and switch to psych on 1.9. There is no other way to emit custom yaml on syck other than using deprecated API. Sorry. :/ ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-05-23 17:43 Message: What version of ruby are you running? I'm not seeing this at all on either 1.8.7 or 1.9.2. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29217&group_id=126 From noreply at rubyforge.org Tue May 24 14:48:35 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 24 May 2011 14:48:35 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29217 ] RubyGems uses deprecated API: YAML.quick_emit Message-ID: <20110524184836.16CB518583B5@rubyforge.org> Bugs item #29217, was opened at 2011-05-20 09:49 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29217&group_id=126 Category: other Group: None Status: Closed Resolution: Rejected Priority: 3 Submitted By: Scott Tadman (tadman) Assigned to: Ryan Davis (zenspider) Summary: RubyGems uses deprecated API: YAML.quick_emit Initial Comment: Running `rake test` on rubygems produces thousands of warnings about YAML.quick_emit being deprecated. This was fixed by Tenderlove with a patch associated with the ticket at http://redmine.ruby-lang.org/issues/show/4163 so it should be easy to repair. After examining the code it seems this warning may not be presented to people if they have warnings turned off, or if they're using a non-syck YAML engine so it may not have been observed by the build team. ---------------------------------------------------------------------- Comment By: Erik Hollensbe (erikh) Date: 2011-05-24 11:48 Message: Ryan, I don't run with Psych and can (and do) routinely test this code path. -Erik ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-05-24 11:31 Message: So, we're in agreement that this situation sucks. ;) I can't _reliably_ test both paths of to_yaml because I can't guarantee that the runtime will have both engines (like you). We do have some tests for to_yaml: 3924 % ack def.test_to_yaml test test/rubygems/test_gem_specification.rb 929: def test_to_yaml 939: def test_to_yaml_fancy 950: def test_to_yaml_platform_empty_string 956: def test_to_yaml_platform_legacy 968: def test_to_yaml_platform_nil but as you can see, none of them are engine specific. As I said before, this is an unfortunate situation, but valid. Syck is going away (it's not even the default engine in 1.9.3) and there is no workaround for this code _in_syck_, so the deprecation warning is valid. I talked tenderlove into improving the message to tell you to install libyaml and switch to psych (which means doing nothing on 1.9.3 and adding a require in ruby < 1.9.3--already done in rubygems). ---------------------------------------------------------------------- Comment By: Scott Tadman (tadman) Date: 2011-05-24 11:02 Message: This is what I'm seeing running tests on 1.9.2. I don't have Psych installed. ........../Users/tadman/git/rubygems/lib/rubygems/specification.rb:1898:in `to_yaml': YAML.quick_emit is deprecated /Users/tadman/git/rubygems/lib/rubygems/specification.rb:1898:in `to_yaml': YAML.quick_emit is deprecated ./Users/tadman/git/rubygems/lib/rubygems/specification.rb:1898:in `to_yaml': YAML.quick_emit is deprecated ./Users/tadman/git/rubygems/lib/rubygems/specification.rb:1898:in `to_yaml': YAML.quick_emit is deprecated ../Users/tadman/git/rubygems/lib/rubygems/specification.rb:1898:in `to_yaml': YAML.quick_emit is deprecated /Users/tadman/git/rubygems/lib/rubygems/specification.rb:1898:in `to_yaml': YAML.quick_emit is deprecated ....../Users/tadman/git/rubygems/lib/rubygems/specification.rb:1898:in `to_yaml': YAML.quick_emit is deprecated /Users/tadman/git/rubygems/lib/rubygems/specification.rb:1898:in `to_yaml': YAML.quick_emit is deprecated ../Users/tadman/git/rubygems/lib/rubygems/specification.rb:1898:in `to_yaml': YAML.quick_emit is deprecated /Users/tadman/git/rubygems/lib/rubygems/specification.rb:1898:in `to_yaml': YAML.quick_emit is deprecated ....../Users/tadman/git/rubygems/lib/rubygems/specification.rb:1898:in `to_yaml': YAML.quick_emit is deprecated ./Users/tadman/git/rubygems/lib/rubygems/specification.rb:1898:in `to_yaml': YAML.quick_emit is deprecated .........../Users/tadman/git/rubygems/lib/rubygems/specification.rb:1898:in `to_yaml': YAML.quick_emit is deprecated /Users/tadman/git/rubygems/lib/rubygems/specification.rb:1898:in `to_yaml': YAML.quick_emit is deprecated /Users/tadman/git/rubygems/lib/rubygems/specification.rb:1898:in `to_yaml': YAML.quick_emit is deprecated /Users/tadman/git/rubygems/lib/rubygems/specification.rb:1898:in `to_yaml': YAML.quick_emit is deprecated /Users/tadman/git/rubygems/lib/rubygems/specification.rb:1898:in `to_yaml': YAML.quick_emit is deprecated /Users/tadman/git/rubygems/lib/rubygems/specification.rb:1898:in `to_yaml': YAML.quick_emit is deprecated /Users/tadman/git/rubygems/lib/rubygems/specification.rb:1898:in `to_yaml': YAML.quick_emit is deprecated /Users/tadman/git/rubygems/lib/rubygems/specification.rb:1898:in `to_yaml': YAML.quick_emit is deprecated /Users/tadman/git/rubygems/lib/rubygems/specification.rb:1898:in `to_yaml': YAML.quick_emit is deprecated It goes on like that for another few thousand lines. Output from irb: > YAML::ENGINE => # This triggers the quick_emit branch in Gem::Specification#to_yaml: def to_yaml(opts = {}) # :nodoc: if YAML.const_defined?(:ENGINE) && !YAML::ENGINE.syck? then super.gsub(/ !!null \n/, " \n") else YAML.quick_emit object_id, opts do |out| out.map taguri, to_yaml_style do |map| encode_with map end end end end Presumably if you have another YAML engine installed or loaded this will not trigger and you will not see the warnings. This branch should be exercised at least once during the tests. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-05-23 17:59 Message: ok... I've got a repro by forcing syck at the top of rubygems.rb and running the tests. I've consulted with tenderlove on this and the only "solution" is to install libyaml and switch to psych on 1.9. There is no other way to emit custom yaml on syck other than using deprecated API. Sorry. :/ ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-05-23 17:43 Message: What version of ruby are you running? I'm not seeing this at all on either 1.8.7 or 1.9.2. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29217&group_id=126 From noreply at rubyforge.org Tue May 24 20:05:01 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 24 May 2011 20:05:01 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29176 ] Scary warnings are scaring helpless developers who can't do a thing about it Message-ID: <20110525000502.8F0BB19783BC@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-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 djberg96 at gmail.com Tue May 24 21:16:29 2011 From: djberg96 at gmail.com (Daniel Berger) Date: Tue, 24 May 2011 19:16:29 -0600 Subject: [Rubygems-developers] Gem.available? deprecation Message-ID: Hi, Just curious, why is Gem.available? being deprecated? Seems a handy method. :) Regards, Dan From noreply at rubyforge.org Tue May 24 22:40:10 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 24 May 2011 22:40:10 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29217 ] RubyGems uses deprecated API: YAML.quick_emit Message-ID: <20110525024010.9FC6A1678325@rubyforge.org> Bugs item #29217, was opened at 2011-05-20 12:49 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29217&group_id=126 Category: other Group: None Status: Closed Resolution: Rejected Priority: 3 Submitted By: Scott Tadman (tadman) Assigned to: Ryan Davis (zenspider) Summary: RubyGems uses deprecated API: YAML.quick_emit Initial Comment: Running `rake test` on rubygems produces thousands of warnings about YAML.quick_emit being deprecated. This was fixed by Tenderlove with a patch associated with the ticket at http://redmine.ruby-lang.org/issues/show/4163 so it should be easy to repair. After examining the code it seems this warning may not be presented to people if they have warnings turned off, or if they're using a non-syck YAML engine so it may not have been observed by the build team. ---------------------------------------------------------------------- >Comment By: Scott Tadman (tadman) Date: 2011-05-24 22:40 Message: Ruby is switching to psych, so that's good news? https://github.com/ruby/ruby/commit/4eaf3d4a511611f0a81d2da23ffb72b7641507f3 Still, it should be possible to force the use of one path through the code for testing purposes. If you have branches, you need tests for both paths. This is presuming the secondary branch is actually required, as it's not clear why it needs such special handling. If I simply force the first branch I get a bunch of errors from failing tests that look like this: 7) Failure: test_build_indicies(TestGemIndexer) [/Users/tadman/git/rubygems/test/rubygems/test_gem_indexer.rb:80]: Expected [["a", Gem::Version.new("1"), "ruby"], ["a", Gem::Version.new("2"), "ruby"], ["a_evil", Gem::Version.new("9"), "ruby"], ["b", Gem::Version.new("2"), "ruby"], ["c", Gem::Version.new("1.2"), "ruby"], ["d", Gem::Version.new("2.0"), "ruby"], ["dep_x", Gem::Version.new("1"), "ruby"], ["pl", Gem::Version.new("1"), "i386-linux"], ["x", Gem::Version.new("1"), "ruby"]], not [["a", Gem::Version.new("1"), "ruby"], ["a", Gem::Version.new("2"), "ruby"], ["a_evil", Gem::Version.new("9"), "ruby"], ["b", Gem::Version.new("2"), "ruby"], ["c", Gem::Version.new("1.2"), "ruby"], ["d", Gem::Version.new("2.0"), "ruby"], ["dep_x", Gem::Version.new("1"), "ruby"], ["pl", Gem::Version.new("1"), "x86-linux"], ["x", Gem::Version.new("1"), "ruby"]]. I've tried to find the origin of this "i386-linux" -> "x86-linux" mapping, which apparently originates in the encode_with method of the same module, as it only manifests when using Syck on the first branch, not Syck on the second or Psych on the first. I'd rather see Syck go, it has a number of serious flaws that have never been properly addressed, but adding libyml as a dependency is going to be a hard sell for non-1.9.3 installs. ---------------------------------------------------------------------- Comment By: Erik Hollensbe (erikh) Date: 2011-05-24 14:48 Message: Ryan, I don't run with Psych and can (and do) routinely test this code path. -Erik ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-05-24 14:31 Message: So, we're in agreement that this situation sucks. ;) I can't _reliably_ test both paths of to_yaml because I can't guarantee that the runtime will have both engines (like you). We do have some tests for to_yaml: 3924 % ack def.test_to_yaml test test/rubygems/test_gem_specification.rb 929: def test_to_yaml 939: def test_to_yaml_fancy 950: def test_to_yaml_platform_empty_string 956: def test_to_yaml_platform_legacy 968: def test_to_yaml_platform_nil but as you can see, none of them are engine specific. As I said before, this is an unfortunate situation, but valid. Syck is going away (it's not even the default engine in 1.9.3) and there is no workaround for this code _in_syck_, so the deprecation warning is valid. I talked tenderlove into improving the message to tell you to install libyaml and switch to psych (which means doing nothing on 1.9.3 and adding a require in ruby < 1.9.3--already done in rubygems). ---------------------------------------------------------------------- Comment By: Scott Tadman (tadman) Date: 2011-05-24 14:02 Message: This is what I'm seeing running tests on 1.9.2. I don't have Psych installed. ........../Users/tadman/git/rubygems/lib/rubygems/specification.rb:1898:in `to_yaml': YAML.quick_emit is deprecated /Users/tadman/git/rubygems/lib/rubygems/specification.rb:1898:in `to_yaml': YAML.quick_emit is deprecated ./Users/tadman/git/rubygems/lib/rubygems/specification.rb:1898:in `to_yaml': YAML.quick_emit is deprecated ./Users/tadman/git/rubygems/lib/rubygems/specification.rb:1898:in `to_yaml': YAML.quick_emit is deprecated ../Users/tadman/git/rubygems/lib/rubygems/specification.rb:1898:in `to_yaml': YAML.quick_emit is deprecated /Users/tadman/git/rubygems/lib/rubygems/specification.rb:1898:in `to_yaml': YAML.quick_emit is deprecated ....../Users/tadman/git/rubygems/lib/rubygems/specification.rb:1898:in `to_yaml': YAML.quick_emit is deprecated /Users/tadman/git/rubygems/lib/rubygems/specification.rb:1898:in `to_yaml': YAML.quick_emit is deprecated ../Users/tadman/git/rubygems/lib/rubygems/specification.rb:1898:in `to_yaml': YAML.quick_emit is deprecated /Users/tadman/git/rubygems/lib/rubygems/specification.rb:1898:in `to_yaml': YAML.quick_emit is deprecated ....../Users/tadman/git/rubygems/lib/rubygems/specification.rb:1898:in `to_yaml': YAML.quick_emit is deprecated ./Users/tadman/git/rubygems/lib/rubygems/specification.rb:1898:in `to_yaml': YAML.quick_emit is deprecated .........../Users/tadman/git/rubygems/lib/rubygems/specification.rb:1898:in `to_yaml': YAML.quick_emit is deprecated /Users/tadman/git/rubygems/lib/rubygems/specification.rb:1898:in `to_yaml': YAML.quick_emit is deprecated /Users/tadman/git/rubygems/lib/rubygems/specification.rb:1898:in `to_yaml': YAML.quick_emit is deprecated /Users/tadman/git/rubygems/lib/rubygems/specification.rb:1898:in `to_yaml': YAML.quick_emit is deprecated /Users/tadman/git/rubygems/lib/rubygems/specification.rb:1898:in `to_yaml': YAML.quick_emit is deprecated /Users/tadman/git/rubygems/lib/rubygems/specification.rb:1898:in `to_yaml': YAML.quick_emit is deprecated /Users/tadman/git/rubygems/lib/rubygems/specification.rb:1898:in `to_yaml': YAML.quick_emit is deprecated /Users/tadman/git/rubygems/lib/rubygems/specification.rb:1898:in `to_yaml': YAML.quick_emit is deprecated /Users/tadman/git/rubygems/lib/rubygems/specification.rb:1898:in `to_yaml': YAML.quick_emit is deprecated It goes on like that for another few thousand lines. Output from irb: > YAML::ENGINE => # This triggers the quick_emit branch in Gem::Specification#to_yaml: def to_yaml(opts = {}) # :nodoc: if YAML.const_defined?(:ENGINE) && !YAML::ENGINE.syck? then super.gsub(/ !!null \n/, " \n") else YAML.quick_emit object_id, opts do |out| out.map taguri, to_yaml_style do |map| encode_with map end end end end Presumably if you have another YAML engine installed or loaded this will not trigger and you will not see the warnings. This branch should be exercised at least once during the tests. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-05-23 20:59 Message: ok... I've got a repro by forcing syck at the top of rubygems.rb and running the tests. I've consulted with tenderlove on this and the only "solution" is to install libyaml and switch to psych on 1.9. There is no other way to emit custom yaml on syck other than using deprecated API. Sorry. :/ ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-05-23 20:43 Message: What version of ruby are you running? I'm not seeing this at all on either 1.8.7 or 1.9.2. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29217&group_id=126 From ryand-ruby at zenspider.com Wed May 25 05:02:18 2011 From: ryand-ruby at zenspider.com (Ryan Davis) Date: Wed, 25 May 2011 02:02:18 -0700 Subject: [Rubygems-developers] Gem.available? deprecation In-Reply-To: References: Message-ID: <50D818CD-3AD1-41D8-8881-FC95F352A87F@zenspider.com> On May 24, 2011, at 18:16 , Daniel Berger wrote: > Just curious, why is Gem.available? being deprecated? Seems a handy method. :) Because too much is on Gem and this is really the responsibility of Specifications to say whether they have something available. Here's the full deprecation: > deprecate :available?, "Specification::find_by_name", 2011, 11 From noreply at rubyforge.org Wed May 25 07:23:37 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 25 May 2011 07:23:37 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29176 ] Scary warnings are scaring helpless developers who can't do a thing about it Message-ID: <20110525112338.241541678326@rubyforge.org> Bugs item #29176, was opened at 2011-05-07 04: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: William Denniss (divzero) Date: 2011-05-25 19: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-25 08: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-23 07: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-23 05: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 16: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-19 04: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-13 05: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-13 05: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-13 00: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 23: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 23: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 15: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-12 07: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-12 02: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 17: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-11 12: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-11 11: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-11 09: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-11 01: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-11 00: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-09 02: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-09 00: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 16:56 Message: No worries. ---------------------------------------------------------------------- Comment By: Justin Collins (presidentbeef) Date: 2011-05-08 14:57 Message: Sorry, my mistake. I didn't notice that gem was called out specifically. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-05-08 14: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-08 14: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-08 14: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-08 13: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-07 06: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-07 05: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-07 04: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-07 04: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-07 04: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 Wed May 25 16:34:59 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 25 May 2011 16:34:59 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29217 ] RubyGems uses deprecated API: YAML.quick_emit Message-ID: <20110525203459.AE23E18583B8@rubyforge.org> Bugs item #29217, was opened at 2011-05-20 09:49 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29217&group_id=126 Category: other Group: None Status: Closed Resolution: Rejected Priority: 3 Submitted By: Scott Tadman (tadman) Assigned to: Ryan Davis (zenspider) Summary: RubyGems uses deprecated API: YAML.quick_emit Initial Comment: Running `rake test` on rubygems produces thousands of warnings about YAML.quick_emit being deprecated. This was fixed by Tenderlove with a patch associated with the ticket at http://redmine.ruby-lang.org/issues/show/4163 so it should be easy to repair. After examining the code it seems this warning may not be presented to people if they have warnings turned off, or if they're using a non-syck YAML engine so it may not have been observed by the build team. ---------------------------------------------------------------------- >Comment By: Ryan Davis (zenspider) Date: 2011-05-25 13:34 Message: It is not possible to force one path vs the other without doing it globally (whole test run). This is because psych adds to_yaml methods to core classes and once they're in place, there is nothing we can (or should) do about it. I've added a check for ENV['TEST_SYCK'] so we can skip loading psych for the sake of testing against syck only. I have a full green test run on both syck (with lots of deprecation warnings) and psych. If you're not getting a clean test run via 'rake TEST_SYCK=1', we need to open a new ticket with details on your environment. ---------------------------------------------------------------------- Comment By: Scott Tadman (tadman) Date: 2011-05-24 19:40 Message: Ruby is switching to psych, so that's good news? https://github.com/ruby/ruby/commit/4eaf3d4a511611f0a81d2da23ffb72b7641507f3 Still, it should be possible to force the use of one path through the code for testing purposes. If you have branches, you need tests for both paths. This is presuming the secondary branch is actually required, as it's not clear why it needs such special handling. If I simply force the first branch I get a bunch of errors from failing tests that look like this: 7) Failure: test_build_indicies(TestGemIndexer) [/Users/tadman/git/rubygems/test/rubygems/test_gem_indexer.rb:80]: Expected [["a", Gem::Version.new("1"), "ruby"], ["a", Gem::Version.new("2"), "ruby"], ["a_evil", Gem::Version.new("9"), "ruby"], ["b", Gem::Version.new("2"), "ruby"], ["c", Gem::Version.new("1.2"), "ruby"], ["d", Gem::Version.new("2.0"), "ruby"], ["dep_x", Gem::Version.new("1"), "ruby"], ["pl", Gem::Version.new("1"), "i386-linux"], ["x", Gem::Version.new("1"), "ruby"]], not [["a", Gem::Version.new("1"), "ruby"], ["a", Gem::Version.new("2"), "ruby"], ["a_evil", Gem::Version.new("9"), "ruby"], ["b", Gem::Version.new("2"), "ruby"], ["c", Gem::Version.new("1.2"), "ruby"], ["d", Gem::Version.new("2.0"), "ruby"], ["dep_x", Gem::Version.new("1"), "ruby"], ["pl", Gem::Version.new("1"), "x86-linux"], ["x", Gem::Version.new("1"), "ruby"]]. I've tried to find the origin of this "i386-linux" -> "x86-linux" mapping, which apparently originates in the encode_with method of the same module, as it only manifests when using Syck on the first branch, not Syck on the second or Psych on the first. I'd rather see Syck go, it has a number of serious flaws that have never been properly addressed, but adding libyml as a dependency is going to be a hard sell for non-1.9.3 installs. ---------------------------------------------------------------------- Comment By: Erik Hollensbe (erikh) Date: 2011-05-24 11:48 Message: Ryan, I don't run with Psych and can (and do) routinely test this code path. -Erik ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-05-24 11:31 Message: So, we're in agreement that this situation sucks. ;) I can't _reliably_ test both paths of to_yaml because I can't guarantee that the runtime will have both engines (like you). We do have some tests for to_yaml: 3924 % ack def.test_to_yaml test test/rubygems/test_gem_specification.rb 929: def test_to_yaml 939: def test_to_yaml_fancy 950: def test_to_yaml_platform_empty_string 956: def test_to_yaml_platform_legacy 968: def test_to_yaml_platform_nil but as you can see, none of them are engine specific. As I said before, this is an unfortunate situation, but valid. Syck is going away (it's not even the default engine in 1.9.3) and there is no workaround for this code _in_syck_, so the deprecation warning is valid. I talked tenderlove into improving the message to tell you to install libyaml and switch to psych (which means doing nothing on 1.9.3 and adding a require in ruby < 1.9.3--already done in rubygems). ---------------------------------------------------------------------- Comment By: Scott Tadman (tadman) Date: 2011-05-24 11:02 Message: This is what I'm seeing running tests on 1.9.2. I don't have Psych installed. ........../Users/tadman/git/rubygems/lib/rubygems/specification.rb:1898:in `to_yaml': YAML.quick_emit is deprecated /Users/tadman/git/rubygems/lib/rubygems/specification.rb:1898:in `to_yaml': YAML.quick_emit is deprecated ./Users/tadman/git/rubygems/lib/rubygems/specification.rb:1898:in `to_yaml': YAML.quick_emit is deprecated ./Users/tadman/git/rubygems/lib/rubygems/specification.rb:1898:in `to_yaml': YAML.quick_emit is deprecated ../Users/tadman/git/rubygems/lib/rubygems/specification.rb:1898:in `to_yaml': YAML.quick_emit is deprecated /Users/tadman/git/rubygems/lib/rubygems/specification.rb:1898:in `to_yaml': YAML.quick_emit is deprecated ....../Users/tadman/git/rubygems/lib/rubygems/specification.rb:1898:in `to_yaml': YAML.quick_emit is deprecated /Users/tadman/git/rubygems/lib/rubygems/specification.rb:1898:in `to_yaml': YAML.quick_emit is deprecated ../Users/tadman/git/rubygems/lib/rubygems/specification.rb:1898:in `to_yaml': YAML.quick_emit is deprecated /Users/tadman/git/rubygems/lib/rubygems/specification.rb:1898:in `to_yaml': YAML.quick_emit is deprecated ....../Users/tadman/git/rubygems/lib/rubygems/specification.rb:1898:in `to_yaml': YAML.quick_emit is deprecated ./Users/tadman/git/rubygems/lib/rubygems/specification.rb:1898:in `to_yaml': YAML.quick_emit is deprecated .........../Users/tadman/git/rubygems/lib/rubygems/specification.rb:1898:in `to_yaml': YAML.quick_emit is deprecated /Users/tadman/git/rubygems/lib/rubygems/specification.rb:1898:in `to_yaml': YAML.quick_emit is deprecated /Users/tadman/git/rubygems/lib/rubygems/specification.rb:1898:in `to_yaml': YAML.quick_emit is deprecated /Users/tadman/git/rubygems/lib/rubygems/specification.rb:1898:in `to_yaml': YAML.quick_emit is deprecated /Users/tadman/git/rubygems/lib/rubygems/specification.rb:1898:in `to_yaml': YAML.quick_emit is deprecated /Users/tadman/git/rubygems/lib/rubygems/specification.rb:1898:in `to_yaml': YAML.quick_emit is deprecated /Users/tadman/git/rubygems/lib/rubygems/specification.rb:1898:in `to_yaml': YAML.quick_emit is deprecated /Users/tadman/git/rubygems/lib/rubygems/specification.rb:1898:in `to_yaml': YAML.quick_emit is deprecated /Users/tadman/git/rubygems/lib/rubygems/specification.rb:1898:in `to_yaml': YAML.quick_emit is deprecated It goes on like that for another few thousand lines. Output from irb: > YAML::ENGINE => # This triggers the quick_emit branch in Gem::Specification#to_yaml: def to_yaml(opts = {}) # :nodoc: if YAML.const_defined?(:ENGINE) && !YAML::ENGINE.syck? then super.gsub(/ !!null \n/, " \n") else YAML.quick_emit object_id, opts do |out| out.map taguri, to_yaml_style do |map| encode_with map end end end end Presumably if you have another YAML engine installed or loaded this will not trigger and you will not see the warnings. This branch should be exercised at least once during the tests. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-05-23 17:59 Message: ok... I've got a repro by forcing syck at the top of rubygems.rb and running the tests. I've consulted with tenderlove on this and the only "solution" is to install libyaml and switch to psych on 1.9. There is no other way to emit custom yaml on syck other than using deprecated API. Sorry. :/ ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-05-23 17:43 Message: What version of ruby are you running? I'm not seeing this at all on either 1.8.7 or 1.9.2. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29217&group_id=126 From drbrain at segment7.net Thu May 26 00:34:32 2011 From: drbrain at segment7.net (Eric Hodel) Date: Wed, 25 May 2011 21:34:32 -0700 Subject: [Rubygems-developers] [ANN] rubygems-update 1.8.4 Released Message-ID: rubygems-update version 1.8.4 has been released! * http://rubygems.org * http://docs.rubygems.org * http://help.rubygems.org * http://github.com/rubygems * http://rubyforge.org/projects/rubygems RubyGems is a package management framework for Ruby. This gem is an update for the RubyGems software. You must have an installation of RubyGems before this update can be applied. See Gem for information on RubyGems (or `ri Gem`) To upgrade to the latest RubyGems, run: $ gem update --system # you might need to be an administrator or root See UPGRADING.rdoc for more details and alternative instructions. ----- If you don't have RubyGems installed, your can still do it manually: * Download from: https://rubygems.org/pages/download * Unpack into a directory and cd there * Install with: ruby setup.rb # you may need admin/root privilege For more details and other options, see: ruby setup.rb --help Changes: === 1.8.4 / 2011-05-25 * 1 minor enhancement: * Removed default_executable deprecations from Specification. From headius at headius.com Thu May 26 02:21:02 2011 From: headius at headius.com (Charles Oliver Nutter) Date: Thu, 26 May 2011 01:21:02 -0500 Subject: [Rubygems-developers] Official public API and hooks, to avoid monkey patches in JRuby et al? Message-ID: Hey there! I haven't been following RubyGems dev lately, but I promised a while back to open a discussion about making it possible for third-party projects to extend RubyGems in a standard way. Specifically, I'm thinking of JRuby's support for installing Java libraries from Maven using RubyGems... gem install mvn:org.clojure:clojure Currently we have a few patches to our installed copy of RG 1.5.1. The changes aren't extensive, but they're invasive where they exist. I believe they patch two aspects: spec retrieval (to formulate a synthetic spec from Maven data) and remote fetching (to build a gem from the Maven artifact on-the-fly). The bulk of the Maven-specific logic exists in separate code not part of the RG codebase, but we do have to hook a few things. So, I have a few questions to kick this off: * Is there a standard, frozen, public RG API that can be used to programmatically install gems, query specs, etc? * Are there standard hooks other than the "defaults" files to make it possible to extend RubyGems with additional packaging systems, transport mechanisms, etc? We can probably start from here and see where it takes us. Thank you! - Charlie From ryand-ruby at zenspider.com Thu May 26 02:55:33 2011 From: ryand-ruby at zenspider.com (Ryan Davis) Date: Wed, 25 May 2011 23:55:33 -0700 Subject: [Rubygems-developers] Official public API and hooks, to avoid monkey patches in JRuby et al? In-Reply-To: References: Message-ID: <97621A01-355E-4AE1-BAC3-BE4C57A307D1@zenspider.com> On May 25, 2011, at 23:21 , Charles Oliver Nutter wrote: > I haven't been following RubyGems dev lately, but I promised a while > back to open a discussion about making it possible for third-party > projects to extend RubyGems in a standard way. Specifically, I'm > thinking of JRuby's support for installing Java libraries from Maven > using RubyGems... > > gem install mvn:org.clojure:clojure > > Currently we have a few patches to our installed copy of RG 1.5.1. The > changes aren't extensive, but they're invasive where they exist. I > believe they patch two aspects: spec retrieval (to formulate a > synthetic spec from Maven data) and remote fetching (to build a gem > from the Maven artifact on-the-fly). The bulk of the Maven-specific > logic exists in separate code not part of the RG codebase, but we do > have to hook a few things. > > So, I have a few questions to kick this off: > > * Is there a standard, frozen, public RG API that can be used to > programmatically install gems, query specs, etc? > * Are there standard hooks other than the "defaults" files to make it > possible to extend RubyGems with additional packaging systems, > transport mechanisms, etc? > > We can probably start from here and see where it takes us. Thank you! So, to add some history (from (faulty) memory): + You and I have talked about this and you pointed me to your patches. + Some of those patches we can address outright. Some, not so easily. + For the easy ones, I already refactored remote_fetcher so that it'll dispatch based on the URL protocol: `send("fetch_#{uri.scheme}", ...)` so you can add fetch_mvn (which is probably just an alias to fetch_http?). + The more difficult ones didn't have obvious refactorings we could do iirc... but I don't remember what they were at this point. In this specific case, is there a reason why the platform default hook isn't an appropriate place to put your extensions? (like, you're hoping to offload this elsewhere or something) From headius at headius.com Thu May 26 06:02:07 2011 From: headius at headius.com (Charles Oliver Nutter) Date: Thu, 26 May 2011 05:02:07 -0500 Subject: [Rubygems-developers] Official public API and hooks, to avoid monkey patches in JRuby et al? In-Reply-To: <97621A01-355E-4AE1-BAC3-BE4C57A307D1@zenspider.com> References: <97621A01-355E-4AE1-BAC3-BE4C57A307D1@zenspider.com> Message-ID: On Thu, May 26, 2011 at 1:55 AM, Ryan Davis wrote: > So, to add some history (from (faulty) memory): > > + You and I have talked about this and you pointed me to your patches. > + Some of those patches we can address outright. Some, not so easily. > + For the easy ones, I already refactored remote_fetcher so that it'll dispatch based on the URL protocol: `send("fetch_#{uri.scheme}", ...)` so you can add fetch_mvn (which is probably just an alias to fetch_http?). This isn't bad, but there's still the spec resolution, dependencies, and so on. These might be the "not so easily" patches, where based on the gem name we branch to mvn logic for resolving a spec. The current JRuby logic essentially hooks spec resolution to go to our logic if it's an "mvn" gem name... FWIW, I have not seen your remote_fetcher refactoring yet...that's homework for me. > + The more difficult ones didn't have obvious refactorings we could do iirc... but I don't remember what they were at this point. The patches we have at the moment are still based on 1.5.1, so we need to try updating to current RubyGems. They are available by diffing the jruby-rubygems_1_5_1 branch against RubyGems 1.5.1 using our forked repository here: https://github.com/jruby/rubygems/tree/jruby-rubygems_1_5_1 The big maven-related file can be mostly ignored; interesting bits are the patches to RG source, which we've tried to keep minimal. I welcome any and all comments on the tweaks we've made here. > In this specific case, is there a reason why the platform default hook isn't an appropriate place to put your extensions? (like, you're hoping to offload this elsewhere or something) Mostly because the spec-related methods in question were large and monolithic. Patching them in defaults would require duplicating their logic in toto but including our changes, which would be less than ideal. Of course without attempting to make the same changes against RG master, I'm not sure if it's an easier monkey patch now. - Charlie From noreply at rubyforge.org Thu May 26 12:19:27 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 26 May 2011 12:19:27 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29229 ] 'gem install spork' installs rake 0.9.0 even though it is not a dependency Message-ID: <20110526161927.2B59718583B4@rubyforge.org> Bugs item #29229, was opened at 2011-05-26 16:19 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29229&group_id=126 Category: `gem install` command Group: None Status: Open Resolution: None Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: Nobody (None) Summary: 'gem install spork' installs rake 0.9.0 even though it is not a dependency Initial Comment: Per the session listed below, installing the spork 0.8.4 gem results in rake 0.9.0 being installed as well, even though there doesn't appear to be any dependency on rake within spork. I've tried reproducing this with other gems, some that have native extensions (like spork) and some that don't, and this is the only gem I could find that is doing this. I also tried this with other rubies and rubygems versions with the same result. I'll put together a list and add it to this ticket. ################################################# $ gem -v 1.8.4 $ ruby -v ruby 1.9.2p0 (2010-08-18 revision 29036) [x86_64-darwin10.4.0] $ gem list *** LOCAL GEMS *** [bundlertest]$ gem install spork Fetching: spork-0.8.4.gem (100%) Building native extensions. This could take a while... Successfully installed spork-0.8.4 1 gem installed [bundlertest]$ gem list rake *** LOCAL GEMS *** rake (0.9.0) $ gem spec spork | grep rake $ ################################################# ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29229&group_id=126 From noreply at rubyforge.org Thu May 26 12:33:47 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 26 May 2011 12:33:47 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29229 ] 'gem install spork' installs rake 0.9.0 even though it is not a dependency Message-ID: <20110526163348.475D218583B4@rubyforge.org> Bugs item #29229, was opened at 2011-05-26 16:19 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29229&group_id=126 Category: `gem install` command Group: None Status: Open Resolution: None Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: Nobody (None) Summary: 'gem install spork' installs rake 0.9.0 even though it is not a dependency Initial Comment: Per the session listed below, installing the spork 0.8.4 gem results in rake 0.9.0 being installed as well, even though there doesn't appear to be any dependency on rake within spork. I've tried reproducing this with other gems, some that have native extensions (like spork) and some that don't, and this is the only gem I could find that is doing this. I also tried this with other rubies and rubygems versions with the same result. I'll put together a list and add it to this ticket. ################################################# $ gem -v 1.8.4 $ ruby -v ruby 1.9.2p0 (2010-08-18 revision 29036) [x86_64-darwin10.4.0] $ gem list *** LOCAL GEMS *** [bundlertest]$ gem install spork Fetching: spork-0.8.4.gem (100%) Building native extensions. This could take a while... Successfully installed spork-0.8.4 1 gem installed [bundlertest]$ gem list rake *** LOCAL GEMS *** rake (0.9.0) $ gem spec spork | grep rake $ ################################################# ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2011-05-26 16:33 Message: I found the source of this: https://github.com/timcharper/spork/blob/master/ext/mkrf_conf.rb Feel free to close. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29229&group_id=126 From noreply at rubyforge.org Thu May 26 13:08:52 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 26 May 2011 13:08:52 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29229 ] 'gem install spork' installs rake 0.9.0 even though it is not a dependency Message-ID: <20110526170852.9B87B18583B4@rubyforge.org> Bugs item #29229, was opened at 2011-05-26 16:19 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29229&group_id=126 Category: `gem install` command Group: None >Status: Closed Resolution: None Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: Nobody (None) Summary: 'gem install spork' installs rake 0.9.0 even though it is not a dependency Initial Comment: Per the session listed below, installing the spork 0.8.4 gem results in rake 0.9.0 being installed as well, even though there doesn't appear to be any dependency on rake within spork. I've tried reproducing this with other gems, some that have native extensions (like spork) and some that don't, and this is the only gem I could find that is doing this. I also tried this with other rubies and rubygems versions with the same result. I'll put together a list and add it to this ticket. ################################################# $ gem -v 1.8.4 $ ruby -v ruby 1.9.2p0 (2010-08-18 revision 29036) [x86_64-darwin10.4.0] $ gem list *** LOCAL GEMS *** [bundlertest]$ gem install spork Fetching: spork-0.8.4.gem (100%) Building native extensions. This could take a while... Successfully installed spork-0.8.4 1 gem installed [bundlertest]$ gem list rake *** LOCAL GEMS *** rake (0.9.0) $ gem spec spork | grep rake $ ################################################# ---------------------------------------------------------------------- >Comment By: James Tucker (raggi) Date: 2011-05-26 17:08 Message: That spork code is really dumb. It's really dumb because it's an mkrf, which means rake /must/ be installed. The forced install of rake really isn't required. We also have platform support that'll deal with the windows side of things, so the whole thing really isn't required. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2011-05-26 16:33 Message: I found the source of this: https://github.com/timcharper/spork/blob/master/ext/mkrf_conf.rb Feel free to close. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29229&group_id=126 From noreply at rubyforge.org Thu May 26 13:11:02 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 26 May 2011 13:11:02 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29229 ] 'gem install spork' installs rake 0.9.0 even though it is not a dependency Message-ID: <20110526171103.0B23F18583B4@rubyforge.org> Bugs item #29229, was opened at 2011-05-26 16:19 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29229&group_id=126 Category: `gem install` command Group: None Status: Closed Resolution: None Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: Nobody (None) Summary: 'gem install spork' installs rake 0.9.0 even though it is not a dependency Initial Comment: Per the session listed below, installing the spork 0.8.4 gem results in rake 0.9.0 being installed as well, even though there doesn't appear to be any dependency on rake within spork. I've tried reproducing this with other gems, some that have native extensions (like spork) and some that don't, and this is the only gem I could find that is doing this. I also tried this with other rubies and rubygems versions with the same result. I'll put together a list and add it to this ticket. ################################################# $ gem -v 1.8.4 $ ruby -v ruby 1.9.2p0 (2010-08-18 revision 29036) [x86_64-darwin10.4.0] $ gem list *** LOCAL GEMS *** [bundlertest]$ gem install spork Fetching: spork-0.8.4.gem (100%) Building native extensions. This could take a while... Successfully installed spork-0.8.4 1 gem installed [bundlertest]$ gem list rake *** LOCAL GEMS *** rake (0.9.0) $ gem spec spork | grep rake $ ################################################# ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2011-05-26 17:11 Message: James, would you please provide advice/insight on this ticket: https://github.com/timcharper/spork/issues/119 Thx ---------------------------------------------------------------------- Comment By: James Tucker (raggi) Date: 2011-05-26 17:08 Message: That spork code is really dumb. It's really dumb because it's an mkrf, which means rake /must/ be installed. The forced install of rake really isn't required. We also have platform support that'll deal with the windows side of things, so the whole thing really isn't required. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2011-05-26 16:33 Message: I found the source of this: https://github.com/timcharper/spork/blob/master/ext/mkrf_conf.rb Feel free to close. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29229&group_id=126 From kgo at grant-olson.net Thu May 26 17:03:34 2011 From: kgo at grant-olson.net (Grant Olson) Date: Thu, 26 May 2011 17:03:34 -0400 Subject: [Rubygems-developers] Proposal for signing gems Message-ID: <4DDEC026.7020207@grant-olson.net> [Round 2. Looks like the list server doesn't like PGP/Mime mails. Apologies if this shows up as a dupe.] I was lucky enough to get to RailsConf this year and I saw Nick's presentation. While thinking about gems and looking at the internal layout, it occurred to me that gems aren't signed and that I've never actually verified a gem. This opens us up to the possibility of downloading and installing a malicious gem posing as a legitimate one. I chatted with Nick for a minute after the presentation. He mentioned that there is some signing functionality built-in, but no one uses it, no one knows if it's designed properly, and it'd be nice to see that change. I took a look at the existing signing functionality. The docs[1] indicate that it uses X509 certificates. With all due respect to the author of the signing code, I don't think this is the best choice. Also, when I attempt to run the command to build an X509 cert in ruby 1.9.2, the command failed. I'd really like to see signed gems, and I'm willing to do the work, but I wanted to run my design by people first and see if we can reach a consensus, rather than writing the code and finding out no one wants the feature. Any and all questions and comments are appreciated. We should sign gems with gpg ============================ I don't think X509 signatures are the way to go. I think we should use OpenPGP signatures instead. 1. Self-signed X509 certificates are basically worthless. There's no easy way to verify that the key is legitimate. OpenPGP certificates are designed to be generated by you, and then signed by other people to validate their authenticity. 2. Setting up an X509 CA will take some resources. OpenPGP already has a dedicated pool of servers run by volunteers at pool.sks-keyservers.net. 3. The current generation policy isn't so good. Your private key isn't encrypted. It's a strange file in a strange location that could easily be lost. In gpg, all files are stored in ~/.gnupg. Private keys are encrypted by default. 4. gpg has better tooling and documentation than openssl. There are plenty of things like Seahorse or GPA to examine your keys. Policies are documented and explained. 5. gpg allows the user to decide their default threat model and key verification model. X509 assumes you trust the powers that be. 6. The OpenPGP certificate will (optionally) be tied to the owner's real life id, if (for example) they sign release emails, use git's signing functionality on release tags, sign binary releases. This makes it easier to verify that the key isn't forged. (See trust model 3 below.) The way I envision it, a gem maintainer would generate and publish a key with gpg if they didn't already have one. He would put the key id in the gem configuration file. When he builds the gem, gpg kicks in and signs it. An end user who wants to verify the key runs a command after fetching the gem. If they have the key, we run gpg and verify the signature. If not, we provide the key id so they can download it manually with gpg. The code to implement this should be pretty simple. Authenticating keys / Certificate authority =========================================== With gpg, the user can determine their trust model. 1. The current model. The user doesn't care. They don't check gpg sigs. All is well. I imagine this will still be the model used by a strong majority of users. 2. The user uses the OpenPGP web of trust. To be honest, this is a PITA. It involves getting into the strong set by meeting people in person and exchanging key fingerprints to make sure that there's no man-in-the-middle attack. And even if the user is in the strong set, there's no guarantee the gem maintainer is. 3. Continuity model. I downloaded the signing key for Ubuntu about four releases ago. Even though I haven't done full verification, there haven't been any reports of problems, and the next three releases were signed by the same key. If the key changed and gpg couldn't verify the next Ubuntu release, it would raise some eyebrows. You can use the same philosophy with gems. 4. Simulated CA. Similar to the way a distributed source control system can be used as a centralized system, the OpenPGP web of trust can be setup to act as if there's a certificate authority. For an example of option 4, look at the PGP Corp Global Directory[2]. You go to the website and submit your public key. It sends you an email that you need to reply to. If you reply, signs your key and publishes the information. If another user trusts the Global Directory key, they will now trust your key. Technically, this is subject to a man-in-the-middle attack. But it's the same policy that gets used when I forget my password at something like Amazon. And Amazon has my credit card info. I think the procedure is valid against all but the most exotic attacks as long as its limitations are known and documented. [For conciseness' sake, I'm just going to pretend we've agreed that rubygems.org is the CA. It could of course be another service, but I think it makes sense to do all this in a centralized place. Right now I'm more concerned with presenting the model.] rubygems.org could: 1. Allow gem publisher to upload a private key from their account page. 2. Upon receipt of key, send an email to the gem publisher's email containing an encrypted token. 3. The gem publisher decrypts the token, 4. The gem publisher posts the decrypted token onto a form at the website and submits. This establishes the gem publisher has control of (a) the email address, and (b) the OpenPGP key. (Excluding a possible mitm at the network level.) 5. rubygems.org signs the key with it's own signing key, possibly with a 6 month or 1 year expiration date. 6. The new signature is submitted to the keyservers at pool.sks-keyservers.net, making the verification available world-wide. Now an unrelated gem user can configure gpg to trust the rubygems signing key. When they download the gem from above and retrieve the gem publisher's key, they will see that the key is valid because it's trusted by rubygems. If it's not trusted, it's up to User B to investigate and determine if they trust the gem or not. Note that the relationship between these keys isn't contained in the gem. It's contained on the keyservers. If another website or mirror provides the same gem with the same signature, it will still show up as valid, assuming the gem user trusts the rubygems.org signing key. In the year 2013 ================ Assuming all goes well, most people are signing their gems, and the community likes the feature, we could configure a keyring for use by gems only, similar to the way apt-get maintains its own keyring. This keyring would automatically include the rubygems.org signing key on installation. When downloading a new gem, verification will happen automatically. If the key isn't on the gem keyring it will be downloaded automatically. If the key isn't trusted, the user will receive a warning and asked if they want to continue. If the signature check fails, the gem will not be installed. [1] http://docs.rubygems.org/read/chapter/21 [2] https://keyserver.pgp.com/vkd/GetWelcomeScreen.event -- Grant "I am gravely disappointed. Again you have made me unleash my dogs of war." From evan at fallingsnow.net Thu May 26 17:56:39 2011 From: evan at fallingsnow.net (Evan Phoenix) Date: Thu, 26 May 2011 14:56:39 -0700 Subject: [Rubygems-developers] Proposal for signing gems In-Reply-To: <4DDEC026.7020207@grant-olson.net> References: <4DDEC026.7020207@grant-olson.net> Message-ID: I apologize for the top posting, but the comment applies to the whole thing. Grant, one of the requirements for any signing strategy is that it can be implemented all in ruby, specifically with things provided by the ruby standard library. This by and large means OpenSSL. Could a PGP-style setup be fully implemented in ruby and hosted entirely by us (not require an pgp keyservers)? -- Evan Phoenix // evan at fallingsnow.net On Thursday, May 26, 2011 at 2:03 PM, Grant Olson wrote: > [Round 2. Looks like the list server doesn't like PGP/Mime mails. > Apologies if this shows up as a dupe.] > > I was lucky enough to get to RailsConf this year and I saw Nick's > presentation. While thinking about gems and looking at the internal > layout, it occurred to me that gems aren't signed and that > I've never actually verified a gem. This opens us up to the possibility > of downloading and installing a malicious gem posing as a legitimate one. > > I chatted with Nick for a minute after the presentation. He mentioned > that there is some signing functionality built-in, but no one uses it, > no one knows if it's designed properly, and it'd be nice to see that change. > > I took a look at the existing signing functionality. The docs[1] > indicate that it uses X509 certificates. With all due respect to the > author of the signing code, I don't think this is the best choice. > Also, when I attempt to run the command to build an X509 cert in ruby > 1.9.2, the command failed. > > I'd really like to see signed gems, and I'm willing to do the work, but > I wanted to run my design by people first and see if we can reach a > consensus, rather than writing the code and finding out no one wants the > feature. > > Any and all questions and comments are appreciated. > > We should sign gems with gpg > ============================ > > I don't think X509 signatures are the way to go. I think we should use > OpenPGP signatures instead. > > 1. Self-signed X509 certificates are basically worthless. There's no > easy way to verify that the key is legitimate. OpenPGP certificates are > designed to be generated by you, and then signed by other people to > validate their authenticity. > > 2. Setting up an X509 CA will take some resources. OpenPGP already has > a dedicated pool of servers run by volunteers at pool.sks-keyservers.net (http://pool.sks-keyservers.net). > > 3. The current generation policy isn't so good. Your private key isn't > encrypted. It's a strange file in a strange location that could easily > be lost. In gpg, all files are stored in ~/.gnupg. Private keys are > encrypted by default. > > 4. gpg has better tooling and documentation than openssl. There are > plenty of things like Seahorse or GPA to examine your keys. Policies > are documented and explained. > > 5. gpg allows the user to decide their default threat model and key > verification model. X509 assumes you trust the powers that be. > > 6. The OpenPGP certificate will (optionally) be tied to the owner's real > life id, if (for example) they sign release emails, use git's signing > functionality on release tags, sign binary releases. This makes it > easier to verify that the key isn't forged. (See trust model 3 below.) > > The way I envision it, a gem maintainer would generate and publish a key > with gpg if they didn't already have one. He would put the key id in > the gem configuration file. When he builds the gem, gpg kicks in and > signs it. > > An end user who wants to verify the key runs a command after fetching > the gem. If they have the key, we run gpg and verify the signature. If > not, we provide the key id so they can download it manually with gpg. > > The code to implement this should be pretty simple. > > Authenticating keys / Certificate authority > =========================================== > > With gpg, the user can determine their trust model. > > 1. The current model. The user doesn't care. They don't check gpg > sigs. All is well. I imagine this will still be the model used by a > strong majority of users. > > 2. The user uses the OpenPGP web of trust. To be honest, this is a > PITA. It involves getting into the strong set by meeting people in > person and exchanging key fingerprints to make sure that there's no > man-in-the-middle attack. And even if the user is in the strong set, > there's no guarantee the gem maintainer is. > > 3. Continuity model. I downloaded the signing key for Ubuntu about four > releases ago. Even though I haven't done full verification, there > haven't been any reports of problems, and the next three releases were > signed by the same key. If the key changed and gpg couldn't verify the > next Ubuntu release, it would raise some eyebrows. You can use the same > philosophy with gems. > > 4. Simulated CA. Similar to the way a distributed source control system > can be used as a centralized system, the OpenPGP web of trust can be > setup to act as if there's a certificate authority. > > For an example of option 4, look at the PGP Corp Global Directory[2]. > You go to the website and submit your public key. It sends you an email > that you need to reply to. If you reply, signs your key and > publishes the information. If another user trusts the Global Directory > key, they will now trust your key. > > Technically, this is subject to a man-in-the-middle attack. But it's > the same policy that gets used when I forget my password at something > like Amazon. And Amazon has my credit card info. I think the > procedure is valid against all but the most exotic attacks as long as > its limitations are known and documented. > > [For conciseness' sake, I'm just going to pretend we've agreed that > rubygems.org (http://rubygems.org) is the CA. It could of course be another service, but I > think it makes sense to do all this in a centralized place. Right now > I'm more concerned with presenting the model.] > > rubygems.org (http://rubygems.org) could: > > 1. Allow gem publisher to upload a private key from their account page. > > 2. Upon receipt of key, send an email to the gem publisher's email > containing an encrypted token. > > 3. The gem publisher decrypts the token, > > 4. The gem publisher posts the decrypted token onto a form at the > website and submits. This establishes the gem publisher has control of > (a) the email address, and (b) the OpenPGP key. (Excluding a possible > mitm at the network level.) > > 5. rubygems.org (http://rubygems.org) signs the key with it's own signing key, possibly with a > 6 month or 1 year expiration date. > > 6. The new signature is submitted to the keyservers at > pool.sks-keyservers.net (http://pool.sks-keyservers.net), making the verification available world-wide. > > Now an unrelated gem user can configure gpg to trust the rubygems > signing key. When they download the gem from above and retrieve the gem > publisher's key, they will see that the key is valid because it's > trusted by rubygems. If it's not trusted, it's up to User B to > investigate and determine if they trust the gem or not. > > Note that the relationship between these keys isn't contained in the > gem. It's contained on the keyservers. If another website or mirror > provides the same gem with the same signature, it will still show up as > valid, assuming the gem user trusts the rubygems.org (http://rubygems.org) signing key. > > In the year 2013 > ================ > > Assuming all goes well, most people are signing their gems, and the > community likes the feature, we could configure a keyring for use by > gems only, similar to the way apt-get maintains its own keyring. > > This keyring would automatically include the rubygems.org (http://rubygems.org) signing key on > installation. When downloading a new gem, verification will happen > automatically. If the key isn't on the gem keyring it will be > downloaded automatically. If the key isn't trusted, the user will > receive a warning and asked if they want to continue. If the signature > check fails, the gem will not be installed. > > [1] http://docs.rubygems.org/read/chapter/21 > [2] https://keyserver.pgp.com/vkd/GetWelcomeScreen.event > > -- > Grant > > "I am gravely disappointed. Again you have made me unleash my dogs of war." > _______________________________________________ > 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 kgo at grant-olson.net Thu May 26 18:34:11 2011 From: kgo at grant-olson.net (Grant Olson) Date: Thu, 26 May 2011 18:34:11 -0400 Subject: [Rubygems-developers] Proposal for signing gems In-Reply-To: References: <4DDEC026.7020207@grant-olson.net> Message-ID: <4DDED563.9080201@grant-olson.net> On 5/26/11 5:56 PM, Evan Phoenix wrote: > I apologize for the top posting, but the comment applies to the whole thing. > > Grant, one of the requirements for any signing strategy is that it can be implemented all in ruby, specifically with things provided by the ruby standard library. This by and large means OpenSSL. > > Could a PGP-style setup be fully implemented in ruby and hosted entirely by us (not require an pgp keyservers)? > My philosophy was to dump as much of the real crypto to the existing infrastructure as possible, so we don't need to worry about bone-headed crypto mistakes in our code. But I see where you're coming from. The proof-of-concept code I have right now just shells out to gpg with backticks and degrades gracefully if there's no gpg. There's no verification, but you can still install the gem, and run rubygems without any external dependencies. If the ruby standard library can deal with the public key signing (RSA and DSA) and hash functions (SHA series, and possibly MD5, RIPEMD160) it would be possible to write a full ruby implemenatation that can process OpenPGP files, but that's a lot of work, and prone to errors. For the second part of the question, I'm not sure if you're asking if we could run our own keyservers, or if we need to be able to verify packages with the network unplugged. The keyserver code is open source, you could run your own keyservers outside of the existing pools if you wanted to. If you wanted to be able to verify gems without network access, you could include official master signing keys (the public portion only) in the rubygem distribution, as I talk about in the last section. The gem maintainer could embed their full public key into the gem, including the signature from the master key, in addition to the package signatures. With this, you would have everything you need verify the package off-line. -- Grant "I am gravely disappointed. Again you have made me unleash my dogs of war." From luislavena at gmail.com Thu May 26 18:38:05 2011 From: luislavena at gmail.com (Luis Lavena) Date: Thu, 26 May 2011 18:38:05 -0400 Subject: [Rubygems-developers] Proposal for signing gems In-Reply-To: <4DDED563.9080201@grant-olson.net> References: <4DDEC026.7020207@grant-olson.net> <4DDED563.9080201@grant-olson.net> Message-ID: On Thu, May 26, 2011 at 6:34 PM, Grant Olson wrote: > On 5/26/11 5:56 PM, Evan Phoenix wrote: >> I apologize for the top posting, but the comment applies to the whole thing. >> >> Grant, one of the requirements for any signing strategy is that it can be implemented all in ruby, specifically with things provided by the ruby standard library. This by and large means OpenSSL. >> >> Could a PGP-style setup be fully implemented in ruby and hosted entirely by us (not require an pgp keyservers)? >> > > My philosophy was to dump as much of the real crypto to the existing > infrastructure as possible, so we don't need to worry about bone-headed > crypto mistakes in our code. ?But I see where you're coming from. > > The proof-of-concept code I have right now just shells out to gpg with > backticks and degrades gracefully if there's no gpg. ?There's no > verification, but you can still install the gem, and run rubygems > without any external dependencies. > That doesn't defeats the purpose of actually having signed/certified gems? As for backticks: on Windows, there is no OpenPGP by default and Ruby works on Windows. It will be system where PGP is not installed at all. -- 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 evan at fallingsnow.net Thu May 26 19:15:45 2011 From: evan at fallingsnow.net (Evan Phoenix) Date: Thu, 26 May 2011 16:15:45 -0700 Subject: [Rubygems-developers] Proposal for signing gems In-Reply-To: <4DDED563.9080201@grant-olson.net> References: <4DDEC026.7020207@grant-olson.net> <4DDED563.9080201@grant-olson.net> Message-ID: <9169DB74B10149F8A69DF991B7FABB1A@gmail.com> See below. -- Evan Phoenix // evan at fallingsnow.net On Thursday, May 26, 2011 at 3:34 PM, Grant Olson wrote: > On 5/26/11 5:56 PM, Evan Phoenix wrote: > > I apologize for the top posting, but the comment applies to the whole thing. > > > > Grant, one of the requirements for any signing strategy is that it can be implemented all in ruby, specifically with things provided by the ruby standard library. This by and large means OpenSSL. > > > > Could a PGP-style setup be fully implemented in ruby and hosted entirely by us (not require an pgp keyservers)? > > My philosophy was to dump as much of the real crypto to the existing > infrastructure as possible, so we don't need to worry about bone-headed > crypto mistakes in our code. But I see where you're coming from. > > The proof-of-concept code I have right now just shells out to gpg with > backticks and degrades gracefully if there's no gpg. There's no > verification, but you can still install the gem, and run rubygems > without any external dependencies. > > If the ruby standard library can deal with the public key signing (RSA > and DSA) and hash functions (SHA series, and possibly MD5, RIPEMD160) it > would be possible to write a full ruby implemenatation that can process > OpenPGP files, but that's a lot of work, and prone to errors. While it is going to be more work, it's the only solution that really makes any sense. We simply can't introduce pgp/gpg as a platform dependency. > > For the second part of the question, I'm not sure if you're asking if we > could run our own keyservers, or if we need to be able to verify > packages with the network unplugged. > > The keyserver code is open source, you could run your own keyservers > outside of the existing pools if you wanted to. Sure, that's what I mean. Rubygems shouldn't go down because keyservers are being worked on, we need to be masters of our own destiny. > > If you wanted to be able to verify gems without network access, you > could include official master signing keys (the public portion only) in > the rubygem distribution, as I talk about in the last section. The gem > maintainer could embed their full public key into the gem, including the > signature from the master key, in addition to the package signatures. > With this, you would have everything you need verify the package off-line. > > -- > Grant > > "I am gravely disappointed. Again you have made me unleash my dogs of war." > _______________________________________________ > 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 May 26 19:16:47 2011 From: evan at fallingsnow.net (Evan Phoenix) Date: Thu, 26 May 2011 16:16:47 -0700 Subject: [Rubygems-developers] Proposal for signing gems In-Reply-To: References: <4DDEC026.7020207@grant-olson.net> <4DDED563.9080201@grant-olson.net> Message-ID: <3FC384ED628C4FDEB7493EB9ECF59CB3@gmail.com> See below. -- Evan Phoenix // evan at fallingsnow.net On Thursday, May 26, 2011 at 3:38 PM, Luis Lavena wrote: > On Thu, May 26, 2011 at 6:34 PM, Grant Olson wrote: > > On 5/26/11 5:56 PM, Evan Phoenix wrote: > > > I apologize for the top posting, but the comment applies to the whole thing. > > > > > > Grant, one of the requirements for any signing strategy is that it can be implemented all in ruby, specifically with things provided by the ruby standard library. This by and large means OpenSSL. > > > > > > Could a PGP-style setup be fully implemented in ruby and hosted entirely by us (not require an pgp keyservers)? > > > > My philosophy was to dump as much of the real crypto to the existing > > infrastructure as possible, so we don't need to worry about bone-headed > > crypto mistakes in our code. But I see where you're coming from. > > > > The proof-of-concept code I have right now just shells out to gpg with > > backticks and degrades gracefully if there's no gpg. There's no > > verification, but you can still install the gem, and run rubygems > > without any external dependencies. > > That doesn't defeats the purpose of actually having signed/certified gems? > > As for backticks: on Windows, there is no OpenPGP by default and Ruby > works on Windows. Which is why requiring a pgp/gpg command on the system is an unacceptable solution. > > It will be system where PGP is not installed at all. > > -- > 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 (mailto:Rubygems-developers at rubyforge.org) > http://rubyforge.org/mailman/listinfo/rubygems-developers From noreply at rubyforge.org Thu May 26 19:32:23 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 26 May 2011 19:32:23 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Feature Requests-29230 ] gem list and gem install should take --yaml flag Message-ID: <20110526233224.3D76818583B8@rubyforge.org> Feature Requests item #29230, was opened at 2011-05-26 16:32 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=578&aid=29230&group_id=126 Category: `gem install` command Group: None Status: Open Resolution: None Priority: 3 Submitted By: Ryan Davis (zenspider) Assigned to: Ryan Davis (zenspider) Summary: gem list and gem install should take --yaml flag Initial Comment: Idea: gem list --yaml | ssh server gem install --yaml ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=578&aid=29230&group_id=126 From noreply at rubyforge.org Thu May 26 19:33:19 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 26 May 2011 19:33:19 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Feature Requests-29231 ] gem install *.gem should do topo sort Message-ID: <20110526233319.8FCBD18583B8@rubyforge.org> Feature Requests item #29231, was opened at 2011-05-26 16:33 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=578&aid=29231&group_id=126 Category: `gem install` command Group: None Status: Open Resolution: None Priority: 3 Submitted By: Ryan Davis (zenspider) Assigned to: Ryan Davis (zenspider) Summary: gem install *.gem should do topo sort Initial Comment: At least, I've had hints that it doesn't... we don't have a test for it, that's for sure. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=578&aid=29231&group_id=126 From noreply at rubyforge.org Thu May 26 20:06:14 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 26 May 2011 20:06:14 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29232 ] undefined method `specifications' for "...path":String Message-ID: <20110527000614.9AD9A18583B8@rubyforge.org> Bugs item #29232, was opened at 2011-05-26 17:06 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29232&group_id=126 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Dave Myron (orangechicken) Assigned to: Nobody (None) 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. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29232&group_id=126 From kgo at grant-olson.net Thu May 26 20:26:43 2011 From: kgo at grant-olson.net (Grant Olson) Date: Thu, 26 May 2011 20:26:43 -0400 Subject: [Rubygems-developers] Proposal for signing gems In-Reply-To: <9169DB74B10149F8A69DF991B7FABB1A@gmail.com> References: <4DDEC026.7020207@grant-olson.net> <4DDED563.9080201@grant-olson.net> <9169DB74B10149F8A69DF991B7FABB1A@gmail.com> Message-ID: <4DDEEFC3.9050608@grant-olson.net> On Thu, May 26, 2011 at 7:15 PM, Evan Phoenix wrote: >> If the ruby standard library can deal with the public key signing (RSA >> and DSA) and hash functions (SHA series, and possibly MD5, RIPEMD160) it >> would be possible to write a full ruby implemenatation that can process >> OpenPGP files, but that's a lot of work, and prone to errors. > While it is going to be more work, it's the only solution that really makes any sense. We simply can't introduce pgp/gpg as a platform dependency. > 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? 2) Does rubygems do any verification of the contents? Will a few extra files in the main .tgz flag the gem as invalid? 3) Is there interest in a simulated CA at a site like rubygems, as described in the original post? -- Grant From kgo at grant-olson.net Thu May 26 21:03:23 2011 From: kgo at grant-olson.net (Grant Olson) Date: Thu, 26 May 2011 21:03:23 -0400 Subject: [Rubygems-developers] Proposal for signing gems In-Reply-To: References: <4DDEC026.7020207@grant-olson.net> <4DDED563.9080201@grant-olson.net> Message-ID: <4DDEF85B.4010607@grant-olson.net> On 5/26/2011 6:38 PM, Luis Lavena wrote: > On Thu, May 26, 2011 at 6:34 PM, Grant Olson wrote: >> >> The proof-of-concept code I have right now just shells out to gpg with >> backticks and degrades gracefully if there's no gpg. There's no >> verification, but you can still install the gem, and run rubygems >> without any external dependencies. >> > > That doesn't defeats the purpose of actually having signed/certified gems? > I don't think so. What percent of people who download any software or distro CD actually check the SHA hashes or gpg signatures? Not very many. But a small minority of security conscious people do. And if the security conscious people find a forged or invalid checksum/sig, the rest of the community will hear about it. > As for backticks: on Windows, there is no OpenPGP by default and Ruby > works on Windows. > > It will be system where PGP is not installed at all. > Yep, I've had to manually install SHA packages and OpenPGP on windows to verify software. People who weren't interested haven't, and everything still worked for them. It's the same thing with an optional flag to verify a gem's signature. But lets not get too hung up on this for now. See my email to Evan below. Let's assume we're starting off with an entirely optional not-part-of-the-standard-ruby-install plug-in, which requires a working gpg. -- Grant From evan at fallingsnow.net Thu May 26 21:08:54 2011 From: evan at fallingsnow.net (Evan Phoenix) Date: Thu, 26 May 2011 18:08:54 -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: <420F9FC1F67745EC8F868A34B4229B96@gmail.com> See below. -- Evan Phoenix // evan at fallingsnow.net On Thursday, May 26, 2011 at 5:26 PM, Grant Olson wrote: > On Thu, May 26, 2011 at 7:15 PM, Evan Phoenix wrote: > > > If the ruby standard library can deal with the public key signing (RSA > > > and DSA) and hash functions (SHA series, and possibly MD5, RIPEMD160) it > > > would be possible to write a full ruby implemenatation that can process > > > OpenPGP files, but that's a lot of work, and prone to errors. > > While it is going to be more work, it's the only solution that really > makes any sense. We simply can't introduce pgp/gpg as a platform dependency. > > 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. You're free to write a rubygems plugin, of course. Avoiding monkey patching methods within rubygems though, since there is no promise those will continue to work. I can't promise anything about a merge unless we see the actual code. > > 1) Is the gpg requirement still a dealbreaker in this scenario? Yep, still a deal breaker, Sorry. No external dependency. > > 2) Does rubygems do any verification of the contents? Will a few extra > files in the main .tgz flag the gem as invalid? There is verification it parts, but I don't recall if it rejects .gem's with extra data in them. I suggest you give it a try and let us know though before you build a whole system. > > 3) Is there interest in a simulated CA at a site like rubygems, as > described in the original post? Do you mean X509 CA (I assume so)? In which case, yes, a rubygems/rubycentral CA is something that has been discussed. > > -- > Grant > _______________________________________________ > 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 nick at quaran.to Thu May 26 21:09:27 2011 From: nick at quaran.to (Nick Quaranto) Date: Thu, 26 May 2011 21:09:27 -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: Just interjecting my opinion in here! This feature was requested a while ago: https://github.com/rubygems/gemcutter/issues/96 But I think the actual "CA" stuff could be an entirely different app than Gemcutter...in a different repo. but at something like https://ca.rubygems.org or https://security.rubygems.org ...something! :) On Thu, May 26, 2011 at 8:26 PM, Grant Olson wrote: > On Thu, May 26, 2011 at 7:15 PM, Evan Phoenix wrote: >>> If the ruby standard library can deal with the public key signing (RSA >>> and DSA) and hash functions (SHA series, and possibly MD5, RIPEMD160) it >>> would be possible to write a full ruby implemenatation that can process >>> OpenPGP files, but that's a lot of work, and prone to errors. >> While it is going to be more work, it's the only solution that really > makes any sense. We simply can't introduce pgp/gpg as a platform dependency. >> > > 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? > > 2) Does rubygems do any verification of the contents? ?Will a few extra > files in the main .tgz flag the gem as invalid? > > 3) Is there interest in a simulated CA at a site like rubygems, as > described in the original post? > > -- > Grant > _______________________________________________ > Rubygems-developers mailing list > http://rubyforge.org/projects/rubygems > Rubygems-developers at rubyforge.org > http://rubyforge.org/mailman/listinfo/rubygems-developers > From kgo at grant-olson.net Thu May 26 22:16:49 2011 From: kgo at grant-olson.net (Grant Olson) Date: Thu, 26 May 2011 22:16:49 -0400 Subject: [Rubygems-developers] Proposal for signing gems In-Reply-To: References: <4DDEC026.7020207@grant-olson.net> <4DDED563.9080201@grant-olson.net> <9169DB74B10149F8A69DF991B7FABB1A@gmail.com> <4DDEEFC3.9050608@grant-olson.net> Message-ID: <4DDF0991.1080300@grant-olson.net> On 5/26/2011 9:09 PM, Nick Quaranto wrote: > Just interjecting my opinion in here! > > This feature was requested a while ago: > > https://github.com/rubygems/gemcutter/issues/96 > > But I think the actual "CA" stuff could be an entirely different app > than Gemcutter...in a different repo. but at something like > https://ca.rubygems.org or https://security.rubygems.org ...something! > :) > Basically with OpenPGP you get this for free. There are already keyservers all over the world that have everyone's keys. pool.sks-keyservers.net has like 50 active nodes run by different people. The last outage was because of DNS problems, and now there are multiple computers in different regions controlling the DNS. Still, if you knew the names of the individual nodes, you could connect to the individual servers even while the pool.sks-keyservers.net DNS entry wasn't resolving. Evan expressed some concern about uptime and relying on third parites, so you could install your own sks-keyserver and sync with the pool, possibly round-robining between this server, pool.sks-keyservers.net, pgp.mit.edu, etc. In this scenario, the gem maintainer creates a key and pushes it to one of the keyservers. Within a few hours it's on all of them. This is a one time operation. After this they can sign all the gems they want with that key. Once that's done, the gem user can retrieve the key from the client, without anything special going on at a website. So like I said, that feature basically gets handled automatically with OpenPGP. There's nothing to do on the server-side, except possibly setting up another keyserver. But the *real problem* is authentication. That's where you'd need some sort of security.rubygems.org app. A little background info: The X509/OpenSSL model imposes a hierarchical model. You've got one master certificate that you trust. Its just an a priori assumption that this top-level certificate is valid. In something like a web browser, it's (basically) hard-coded into the app. From there you can verify that the next level is certified to approve certificates, and the gems signed by those certificates. OpenPGP uses a web-of-trust. That's more like six-degrees-of-Kevin-Bacon. There are a bunch of bogus keys out there for president at whitehouse.gov: http://pgp.mit.edu:11371/pks/lookup?search=president%40whitehouse.gov&op=index That might look like a security problem, but it's not. Because there's no path from you to these bogus keys. Assuming one of them was real, then maybe it's signed by Joe Biden's key. And your uncle is on Joe Biden's bowling team, so he signed that key. And you of course know your uncle, so you know the key is good by following the path: Me -> My Uncle -> Joe Biden -> president at whitehouse.gov. In comp-sci terms, the X509 model is a tree, and the OpenPGP model is a graph. But trees are subsets of graphs. And that's where the rubygems.org app would come in. It becomes the equivalent of your uncle or Joe Biden in the above scenario. It provides the connection between you and the gem maintainer: Me -> security.rubygems.org -> thought-bot It can't verify that the app isn't malicious. It can't verify that you're really the president at whitehouse.gov. What it can verify is that the gem you have was (1) created by the appropriate rubygems user account, and that (2) it hasn't been tampered with. It can verify that the gem isn't signed by a bogus thought-bot key that a malicious user created on their machine and published to the keysevers. This malicious key becomes a single point disconnected from the web of trust. To do this, it needs to verify that the user controls their email address and the key. The original post describes how this is done. It signs the thought-bot key by performing some reasonable checks. You sign the rubygems key either because that's hard-coded into the app, like an X509 certificate, or because you've done it manually after (for example) verifying the key fingerprint on the rubygems website. That's why i lean towards tying this signature directly to your rubygems account, because that account is a somewhat authoritatively tied to the gem maintainer. I can still see the advantage of setting this up as a separate app, especially when we're not even sure if people will sign gems even with an end-to-end system in place. -- Grant From noreply at rubyforge.org Fri May 27 19:30:12 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 27 May 2011 19:30:12 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29232 ] undefined method `specifications' for "...path":String Message-ID: <20110527233012.DAE661858363@rubyforge.org> Bugs item #29232, was opened at 2011-05-26 20:06 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29232&group_id=126 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Dave Myron (orangechicken) Assigned to: Nobody (None) 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: Michael Bleigh (mbleigh) Date: 2011-05-27 19: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 Sat May 28 19:58:57 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 28 May 2011 19:58:57 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29232 ] undefined method `specifications' for "...path":String Message-ID: <20110528235857.27093167816A@rubyforge.org> Bugs item #29232, was opened at 2011-05-26 17:06 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29232&group_id=126 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Dave Myron (orangechicken) Assigned to: Nobody (None) >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: Ryan Davis (zenspider) Date: 2011-05-28 16: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 16: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 Mon May 30 09:54:07 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 30 May 2011 09:54:07 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29236 ] native extension installation exposes a back door through which gems can be installed with no management Message-ID: <20110530135407.B93A518583AD@rubyforge.org> Bugs item #29236, was opened at 2011-05-30 13:54 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29236&group_id=126 Category: `gem install` command (extensions) Group: next Status: Open Resolution: None Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: Nobody (None) Summary: native extension installation exposes a back door through which gems can be installed with no management Initial Comment: Per http://rubyforge.org/tracker/?group_id=126&atid=575&func=detail&aid=29229, spork's maintainer used ext/mkrf_conf.rb to install other gems (see https://github.com/timcharper/spork/blob/45675372a2143136705b2ea1b1aa32d420f1caf4/ext/mkrf_conf.rb). This resulted in rake-0.9.0 being installed but it was not reported by the `gem install` command, so we learned about it later. This has been addressed in the spork project, however other projects can still do this. I think this should either be prevented or it should be managed by Rubygems and reported in the output from the `gem install` command. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29236&group_id=126 From noreply at rubyforge.org Mon May 30 10:38:50 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 30 May 2011 10:38:50 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29236 ] native extension installation exposes a back door through which gems can be installed with no management Message-ID: <20110530143850.E1A7D18583AD@rubyforge.org> Bugs item #29236, was opened at 2011-05-30 13:54 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29236&group_id=126 Category: `gem install` command (extensions) Group: next Status: Open Resolution: None Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: Nobody (None) Summary: native extension installation exposes a back door through which gems can be installed with no management Initial Comment: Per http://rubyforge.org/tracker/?group_id=126&atid=575&func=detail&aid=29229, spork's maintainer used ext/mkrf_conf.rb to install other gems (see https://github.com/timcharper/spork/blob/45675372a2143136705b2ea1b1aa32d420f1caf4/ext/mkrf_conf.rb). This resulted in rake-0.9.0 being installed but it was not reported by the `gem install` command, so we learned about it later. This has been addressed in the spork project, however other projects can still do this. I think this should either be prevented or it should be managed by Rubygems and reported in the output from the `gem install` command. ---------------------------------------------------------------------- Comment By: Steve Klabnik (steveklabnik) Date: 2011-05-30 14:38 Message: How would one be able to prevent or manage this? mkmf.rb is just a Ruby script, so if it contains a simple `gem install lolz`, it's gonna happen. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29236&group_id=126 From noreply at rubyforge.org Mon May 30 11:28:00 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 30 May 2011 11:28:00 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29236 ] native extension installation exposes a back door through which gems can be installed with no management Message-ID: <20110530152800.19CE918583B1@rubyforge.org> Bugs item #29236, was opened at 2011-05-30 13:54 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29236&group_id=126 Category: `gem install` command (extensions) Group: next Status: Open Resolution: None Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: Nobody (None) Summary: native extension installation exposes a back door through which gems can be installed with no management Initial Comment: Per http://rubyforge.org/tracker/?group_id=126&atid=575&func=detail&aid=29229, spork's maintainer used ext/mkrf_conf.rb to install other gems (see https://github.com/timcharper/spork/blob/45675372a2143136705b2ea1b1aa32d420f1caf4/ext/mkrf_conf.rb). This resulted in rake-0.9.0 being installed but it was not reported by the `gem install` command, so we learned about it later. This has been addressed in the spork project, however other projects can still do this. I think this should either be prevented or it should be managed by Rubygems and reported in the output from the `gem install` command. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2011-05-30 15:27 Message: `gem` is a rubygems command, so rubygems can know when it's being called, even if it's in a separate process (via setting and checking env vars). ---------------------------------------------------------------------- Comment By: Steve Klabnik (steveklabnik) Date: 2011-05-30 14:38 Message: How would one be able to prevent or manage this? mkmf.rb is just a Ruby script, so if it contains a simple `gem install lolz`, it's gonna happen. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29236&group_id=126 From noreply at rubyforge.org Mon May 30 11:31:56 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 30 May 2011 11:31:56 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29236 ] native extension installation exposes a back door through which gems can be installed with no management Message-ID: <20110530153156.B5F9218583B1@rubyforge.org> Bugs item #29236, was opened at 2011-05-30 13:54 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29236&group_id=126 Category: `gem install` command (extensions) Group: next Status: Open Resolution: None Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: Nobody (None) Summary: native extension installation exposes a back door through which gems can be installed with no management Initial Comment: Per http://rubyforge.org/tracker/?group_id=126&atid=575&func=detail&aid=29229, spork's maintainer used ext/mkrf_conf.rb to install other gems (see https://github.com/timcharper/spork/blob/45675372a2143136705b2ea1b1aa32d420f1caf4/ext/mkrf_conf.rb). This resulted in rake-0.9.0 being installed but it was not reported by the `gem install` command, so we learned about it later. This has been addressed in the spork project, however other projects can still do this. I think this should either be prevented or it should be managed by Rubygems and reported in the output from the `gem install` command. ---------------------------------------------------------------------- Comment By: Steve Klabnik (steveklabnik) Date: 2011-05-30 15:31 Message: I admittedly am not that knowledgeable about Rubygems' internals, so if you say so. That makes sense, but it also seems complicated and error-prone. While that situation kinda sucked (I was bit by it myself), I'm not sure that any software needs to be written to address this. I'd rather use it as a chance to educate gem developers on best practices, as at worst to 'fix' something like this is a 'gem uninstall rake' away. But I can certainly see the advantages of some kind of warning, too. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2011-05-30 15:27 Message: `gem` is a rubygems command, so rubygems can know when it's being called, even if it's in a separate process (via setting and checking env vars). ---------------------------------------------------------------------- Comment By: Steve Klabnik (steveklabnik) Date: 2011-05-30 14:38 Message: How would one be able to prevent or manage this? mkmf.rb is just a Ruby script, so if it contains a simple `gem install lolz`, it's gonna happen. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29236&group_id=126 From noreply at rubyforge.org Mon May 30 11:40:03 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 30 May 2011 11:40:03 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29236 ] native extension installation exposes a back door through which gems can be installed with no management Message-ID: <20110530154003.CE15818583B3@rubyforge.org> Bugs item #29236, was opened at 2011-05-30 10:54 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29236&group_id=126 Category: `gem install` command (extensions) Group: next Status: Open Resolution: None Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: Nobody (None) Summary: native extension installation exposes a back door through which gems can be installed with no management Initial Comment: Per http://rubyforge.org/tracker/?group_id=126&atid=575&func=detail&aid=29229, spork's maintainer used ext/mkrf_conf.rb to install other gems (see https://github.com/timcharper/spork/blob/45675372a2143136705b2ea1b1aa32d420f1caf4/ext/mkrf_conf.rb). This resulted in rake-0.9.0 being installed but it was not reported by the `gem install` command, so we learned about it later. This has been addressed in the spork project, however other projects can still do this. I think this should either be prevented or it should be managed by Rubygems and reported in the output from the `gem install` command. ---------------------------------------------------------------------- >Comment By: Luis Lavena (luislavena) Date: 2011-05-30 12:40 Message: By nature building extensions is a dangerous process. Before rvm-era, doing gem installation involved 'sudo' elevation. extconf.rb is executed directly from Ruby and actions like FileUtils.rm_rf or shell out to `rm` is also possible. The nature of the extconf configuration and compilation make it hard to run on a sandbox/safe level environment. We end trusting gem authors do the right thing, but the problem is knowing that is right and what is wrong, and that is exposed by the lack of documentation and good practices in relation to this. Nick Quaranto started the RubyGems guides with the aim of educate people: http://guides.rubygems.org/ I suck at copy writing (english or my native spanish) so I leave it the ones that are more verse on it. ---------------------------------------------------------------------- Comment By: Steve Klabnik (steveklabnik) Date: 2011-05-30 12:31 Message: I admittedly am not that knowledgeable about Rubygems' internals, so if you say so. That makes sense, but it also seems complicated and error-prone. While that situation kinda sucked (I was bit by it myself), I'm not sure that any software needs to be written to address this. I'd rather use it as a chance to educate gem developers on best practices, as at worst to 'fix' something like this is a 'gem uninstall rake' away. But I can certainly see the advantages of some kind of warning, too. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2011-05-30 12:27 Message: `gem` is a rubygems command, so rubygems can know when it's being called, even if it's in a separate process (via setting and checking env vars). ---------------------------------------------------------------------- Comment By: Steve Klabnik (steveklabnik) Date: 2011-05-30 11:38 Message: How would one be able to prevent or manage this? mkmf.rb is just a Ruby script, so if it contains a simple `gem install lolz`, it's gonna happen. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29236&group_id=126 From noreply at rubyforge.org Mon May 30 17:47:25 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 30 May 2011 17:47:25 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29116 ] Mega slowness in custom require Message-ID: <20110530214726.1EF701D780F9@rubyforge.org> Bugs item #29116, was opened at 2011-04-05 14: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: Nick Rogers (tsp435cds) Date: 2011-05-30 17: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 20: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 19: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 11:20 Message: This is still happening in 1.8.3. ---------------------------------------------------------------------- Comment By: Dan Peterson (dpiddy) Date: 2011-05-04 21: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 14: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 14: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 Mon May 30 21:05:03 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 30 May 2011 21:05:03 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Feature Requests-29240 ] Rename `gem sandbox remove` to `gem sandbox uninstall` Message-ID: <20110531010503.8788F18583B9@rubyforge.org> Feature Requests item #29240, was opened at 2011-05-30 21:05 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=578&aid=29240&group_id=126 Category: `gem` commands Group: None Status: Open Resolution: None Priority: 3 Submitted By: Ian Eccles (iande) Assigned to: Nobody (None) Summary: Rename `gem sandbox remove` to `gem sandbox uninstall` Initial Comment: I apologize if this is not the appropriate place to discuss the rubygems-sandbox feature. Although `gem sandbox remove` is not yet implemented, I'd like to suggest renaming it to `gem sandbox uninstall` for consistency with the standard `gem uninstall` command. So far, this feature seems to be working pretty well. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=578&aid=29240&group_id=126 From noreply at rubyforge.org Mon May 30 23:01:42 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 30 May 2011 23:01:42 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Feature Requests-29241 ] There should be a central source for RubyGems announcements (blog?) Message-ID: <20110531030143.8F81418583B5@rubyforge.org> Feature Requests item #29241, was opened at 2011-05-31 03:01 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=578&aid=29241&group_id=126 Category: `gem` commands Group: None Status: Open Resolution: None Priority: 3 Submitted By: Gregory Brown (binarywaterfall) Assigned to: Nobody (None) Summary: There should be a central source for RubyGems announcements (blog?) Initial Comment: Ryan, This is to remind you that there should be a blog on rubygems.org or somewhere else that's highly visible so that folks can go there to find release notes and annoucements. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=578&aid=29241&group_id=126 From noreply at rubyforge.org Mon May 30 23:03:10 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 30 May 2011 23:03:10 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Feature Requests-29242 ] Add pages to rubygems.org about contributing / getting help Message-ID: <20110531030310.8147318583B5@rubyforge.org> Feature Requests item #29242, was opened at 2011-05-31 03:03 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=578&aid=29242&group_id=126 Category: documentation Group: None Status: Open Resolution: None Priority: 3 Submitted By: Gregory Brown (binarywaterfall) Assigned to: Nobody (None) Summary: Add pages to rubygems.org about contributing / getting help Initial Comment: Actually, this page might be best if it explains what RubyGems, Gemcutter, and Bundler all are, and then links off to 'how to contribute' as well as 'how to get help' documents for each of them. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=578&aid=29242&group_id=126 From noreply at rubyforge.org Mon May 30 23:05:31 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 30 May 2011 23:05:31 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Feature Requests-29243 ] Write up a guide / documentation about the plugin system Message-ID: <20110531030531.1C22218583B5@rubyforge.org> Feature Requests item #29243, was opened at 2011-05-31 03:05 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=578&aid=29243&group_id=126 Category: documentation Group: None Status: Open Resolution: None Priority: 3 Submitted By: Gregory Brown (binarywaterfall) Assigned to: Nobody (None) Summary: Write up a guide / documentation about the plugin system Initial Comment: Folks should know what the plugin system is, what it's intended use is, that there are some things it *isn't* meant to be used for, but also, where to go to ask for help to determine whether something is a good fit for the plugin system and/or ask for extension points to be added to the plugin system API. I will do some research on my own on this if there is time available and contribute if I end up coming up with anything useful, but please don't let that stop anyone who's actively working on RubyGems from beating me to it. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=578&aid=29243&group_id=126 From noreply at rubyforge.org Mon May 30 23:13:28 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 30 May 2011 23:13:28 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Feature Requests-29244 ] Consider moving to Github Issues Message-ID: <20110531031328.E334118583B9@rubyforge.org> Feature Requests item #29244, was opened at 2011-05-31 03:13 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=578&aid=29244&group_id=126 Category: other Group: None Status: Open Resolution: None Priority: 3 Submitted By: Gregory Brown (binarywaterfall) Assigned to: Nobody (None) Summary: Consider moving to Github Issues Initial Comment: Ryan, I know you still have some research that needs to be done here, but please consider moving to Github Issues or post some details on why you can't/won't on the Rubygems blog once that's set up. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=578&aid=29244&group_id=126 From uwe at datek.no Tue May 31 10:31:33 2011 From: uwe at datek.no (Uwe Kubosch) Date: Tue, 31 May 2011 14:31:33 +0000 Subject: [Rubygems-developers] Releasing gems for ruboto (JRuby on Android) Message-ID: <3D1B361D-C145-4F2D-81C3-401FE973A752@datek.no> Hi all! I would like to write a tutorial on how to best release a gem for ruboto, JRuby on Android. But I have no clue as to what is needed, yet. :) I have relased gems before, but not platform specific gems, and not for Ruboto. Can you help me? What do I need to do differently to limit installation to Ruboto projects? The installation itself is done only on the developer's platform. We are currently using Bundler with a Gemfile that simply lists the desired gems. The gems are then installed using Bundler in a separate gem directory using "bundle install --path=". After installation the gems are packaged into a bundle.jar that is packaged and deployed inside the Android app. The two features I know I am missing, is marking a gem as Ruboto-specific (preferably with the same name as other variants of the same gem), and limiting installation of gems to only include gems compatible with Ruboto. The first feature is what I think is the most important. A concrete example would be that the Gemfile includes "gem 'json'" and that a Ruboto specific version of the json gem is installed instead of C-extension based or Java based variants of the json gem. It is not desirable to include the Ruboto specific implementation in the main json gem, since we package the complete "lib" directory of the gem into the apk (Android application package), and every KB counts. This is the first post from me on the subject, and indeed on this list, and I hope you will forgive my ignorance and bad assumptions. Many thanks in advance for any help you can give. -- Uwe Kubosch Systems Developer Datek Wireless AS uwe at datek.no http://datek.no/ From evan at fallingsnow.net Tue May 31 11:56:07 2011 From: evan at fallingsnow.net (Evan Phoenix) Date: Tue, 31 May 2011 08:56:07 -0700 Subject: [Rubygems-developers] Releasing gems for ruboto (JRuby on Android) In-Reply-To: <3D1B361D-C145-4F2D-81C3-401FE973A752@datek.no> References: <3D1B361D-C145-4F2D-81C3-401FE973A752@datek.no> Message-ID: <16B69018B2894997A0344867B26E3044@gmail.com> Hi Uwe, Your question is best answered by either people who work on Ruboto (I believe they have released a gem) or in a generic ruby mailing list. This list is for discussions about the development of rubygems software itself. - Evan -- Evan Phoenix // evan at fallingsnow.net On Tuesday, May 31, 2011 at 7:31 AM, Uwe Kubosch wrote: > Hi all! > > I would like to write a tutorial on how to best release a gem for ruboto, JRuby on Android. > > But I have no clue as to what is needed, yet. :) I have relased gems before, but not platform specific gems, and not for Ruboto. Can you help me? What do I need to do differently to limit installation to Ruboto projects? > > The installation itself is done only on the developer's platform. We are currently using Bundler with a Gemfile that simply lists the desired gems. The gems are then installed using Bundler in a separate gem directory using "bundle install --path=". After installation the gems are packaged into a bundle.jar that is packaged and deployed inside the Android app. > > The two features I know I am missing, is marking a gem as Ruboto-specific (preferably with the same name as other variants of the same gem), and limiting installation of gems to only include gems compatible with Ruboto. The first feature is what I think is the most important. > > A concrete example would be that the Gemfile includes "gem 'json'" and that a Ruboto specific version of the json gem is installed instead of C-extension based or Java based variants of the json gem. > > It is not desirable to include the Ruboto specific implementation in the main json gem, since we package the complete "lib" directory of the gem into the apk (Android application package), and every KB counts. > > This is the first post from me on the subject, and indeed on this list, and I hope you will forgive my ignorance and bad assumptions. Many thanks in advance for any help you can give. > > > -- > Uwe Kubosch > Systems Developer > Datek Wireless AS > uwe at datek.no (mailto:uwe at datek.no) > http://datek.no/ > > > _______________________________________________ > 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 uwe at datek.no Tue May 31 12:09:46 2011 From: uwe at datek.no (Uwe Kubosch) Date: Tue, 31 May 2011 16:09:46 +0000 Subject: [Rubygems-developers] Releasing gems for ruboto (JRuby on Android) In-Reply-To: <16B69018B2894997A0344867B26E3044@gmail.com> References: <3D1B361D-C145-4F2D-81C3-401FE973A752@datek.no> <16B69018B2894997A0344867B26E3044@gmail.com> Message-ID: <56C1C8E2-E846-4354-BF89-69DCC631B180@datek.no> Hi! Thank you for your answer. I thought this might be the right place in case there was a need to define a new platform or OS for RubyGems. 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 will ask in ruby-lang, then. My apologies for the noise. On 2011-05-31, at 17:56, Evan Phoenix wrote: > Hi Uwe, > > Your question is best answered by either people who work on Ruboto (I believe they have released a gem) or in a generic ruby mailing list. This list is for discussions about the development of rubygems software itself. > > - Evan > > -- > Evan Phoenix // evan at fallingsnow.net > > > On Tuesday, May 31, 2011 at 7:31 AM, Uwe Kubosch wrote: > >> Hi all! >> >> I would like to write a tutorial on how to best release a gem for ruboto, JRuby on Android. >> >> But I have no clue as to what is needed, yet. :) I have relased gems before, but not platform specific gems, and not for Ruboto. Can you help me? What do I need to do differently to limit installation to Ruboto projects? >> >> The installation itself is done only on the developer's platform. We are currently using Bundler with a Gemfile that simply lists the desired gems. The gems are then installed using Bundler in a separate gem directory using "bundle install --path=". After installation the gems are packaged into a bundle.jar that is packaged and deployed inside the Android app. >> >> The two features I know I am missing, is marking a gem as Ruboto-specific (preferably with the same name as other variants of the same gem), and limiting installation of gems to only include gems compatible with Ruboto. The first feature is what I think is the most important. >> >> A concrete example would be that the Gemfile includes "gem 'json'" and that a Ruboto specific version of the json gem is installed instead of C-extension based or Java based variants of the json gem. >> >> It is not desirable to include the Ruboto specific implementation in the main json gem, since we package the complete "lib" directory of the gem into the apk (Android application package), and every KB counts. >> >> This is the first post from me on the subject, and indeed on this list, and I hope you will forgive my ignorance and bad assumptions. Many thanks in advance for any help you can give. -- Uwe Kubosch Systems Developer Datek Wireless AS uwe at datek.no http://datek.no/ From evan at fallingsnow.net Tue May 31 12:14:33 2011 From: evan at fallingsnow.net (Evan Phoenix) Date: Tue, 31 May 2011 09:14:33 -0700 Subject: [Rubygems-developers] Releasing gems for ruboto (JRuby on Android) In-Reply-To: <56C1C8E2-E846-4354-BF89-69DCC631B180@datek.no> References: <3D1B361D-C145-4F2D-81C3-401FE973A752@datek.no> <16B69018B2894997A0344867B26E3044@gmail.com> <56C1C8E2-E846-4354-BF89-69DCC631B180@datek.no> Message-ID: <63E1BD9318F6470E9B4940C87E775361@gmail.com> See below. -- Evan Phoenix // evan at fallingsnow.net On Tuesday, May 31, 2011 at 9:09 AM, Uwe Kubosch wrote: > Hi! > > Thank you for your answer. I thought this might be the right place in case there was a need to define a new platform or OS for RubyGems. You don't need rubygems itself to define a platform, it allows anything and validates it against what ruby -v indicates. > > 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. Beyond that, Rubygems doesn't have a mechanism to restrict where gems can be installed. > > I will ask in ruby-lang, then. > > My apologies for the noise. No problem at all. > > > On 2011-05-31, at 17:56, Evan Phoenix wrote: > > > Hi Uwe, > > > > Your question is best answered by either people who work on Ruboto (I believe they have released a gem) or in a generic ruby mailing list. This list is for discussions about the development of rubygems software itself. > > > > - Evan > > > > -- > > Evan Phoenix // evan at fallingsnow.net (mailto:evan at fallingsnow.net) > > > > > > On Tuesday, May 31, 2011 at 7:31 AM, Uwe Kubosch wrote: > > > > > Hi all! > > > > > > I would like to write a tutorial on how to best release a gem for ruboto, JRuby on Android. > > > > > > But I have no clue as to what is needed, yet. :) I have relased gems before, but not platform specific gems, and not for Ruboto. Can you help me? What do I need to do differently to limit installation to Ruboto projects? > > > > > > The installation itself is done only on the developer's platform. We are currently using Bundler with a Gemfile that simply lists the desired gems. The gems are then installed using Bundler in a separate gem directory using "bundle install --path=". After installation the gems are packaged into a bundle.jar that is packaged and deployed inside the Android app. > > > > > > The two features I know I am missing, is marking a gem as Ruboto-specific (preferably with the same name as other variants of the same gem), and limiting installation of gems to only include gems compatible with Ruboto. The first feature is what I think is the most important. > > > > > > A concrete example would be that the Gemfile includes "gem 'json'" and that a Ruboto specific version of the json gem is installed instead of C-extension based or Java based variants of the json gem. > > > > > > It is not desirable to include the Ruboto specific implementation in the main json gem, since we package the complete "lib" directory of the gem into the apk (Android application package), and every KB counts. > > > > > > This is the first post from me on the subject, and indeed on this list, and I hope you will forgive my ignorance and bad assumptions. Many thanks in advance for any help you can give. > > -- > Uwe Kubosch > Systems Developer > Datek Wireless AS > uwe at datek.no (mailto:uwe at datek.no) > http://datek.no/ > > > _______________________________________________ > 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 uwe at datek.no Tue May 31 12:40:45 2011 From: uwe at datek.no (Uwe Kubosch) Date: Tue, 31 May 2011 16:40:45 +0000 Subject: [Rubygems-developers] Releasing gems for ruboto (JRuby on Android) In-Reply-To: <63E1BD9318F6470E9B4940C87E775361@gmail.com> References: <3D1B361D-C145-4F2D-81C3-401FE973A752@datek.no> <16B69018B2894997A0344867B26E3044@gmail.com> <56C1C8E2-E846-4354-BF89-69DCC631B180@datek.no> <63E1BD9318F6470E9B4940C87E775361@gmail.com> Message-ID: On 2011-05-31, at 18:14, Evan Phoenix wrote: >> Thank you for your answer. I thought this might be the right place in case there was a need to define a new platform or OS for RubyGems. > You don't need rubygems itself to define a platform, it allows anything and validates it against what ruby -v indicates. And if I am on OS X, but want to fetch gems for JRuby or Ruboto, I might use the "--platform java" or "--platform ruboto" options to get the desired gem variants? Can I use both? >> 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. Thank you for your help. -- Uwe Kubosch Systems Developer Datek Wireless AS uwe at datek.no http://datek.no/ From evan at fallingsnow.net Tue May 31 12:48:37 2011 From: evan at fallingsnow.net (Evan Phoenix) Date: Tue, 31 May 2011 09:48:37 -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: <13C53118F617455EAE5256D755589493@gmail.com> See below. -- Evan Phoenix // evan at fallingsnow.net On Tuesday, May 31, 2011 at 9:40 AM, Uwe Kubosch wrote: > On 2011-05-31, at 18:14, Evan Phoenix wrote: > > > > Thank you for your answer. I thought this might be the right place in case there was a need to define a new platform or OS for RubyGems. > > You don't need rubygems itself to define a platform, it allows anything and validates it against what ruby -v indicates. > > And if I am on OS X, but want to fetch gems for JRuby or Ruboto, I might use the "--platform java" or "--platform ruboto" options to get the desired gem variants? Can I use both? Yes, but you should generally not use the rubygems platform specifier to restrict users from using the gem unless it contains platform specific code. So if the gems work fine NOT on android, they should just be normal gems. > > > > 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. Give it a shot, but we generally don't recommend this path unless there is platform specific code in the gem. If this does work out for you, let us know. > > Thank you for your help. > > -- > Uwe Kubosch > Systems Developer > Datek Wireless AS > uwe at datek.no (mailto:uwe at datek.no) > http://datek.no/ > > > _______________________________________________ > 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 uwe at datek.no Tue May 31 12:54:55 2011 From: uwe at datek.no (Uwe Kubosch) Date: Tue, 31 May 2011 16:54:55 +0000 Subject: [Rubygems-developers] Releasing gems for ruboto (JRuby on Android) In-Reply-To: <13C53118F617455EAE5256D755589493@gmail.com> References: <3D1B361D-C145-4F2D-81C3-401FE973A752@datek.no> <16B69018B2894997A0344867B26E3044@gmail.com> <56C1C8E2-E846-4354-BF89-69DCC631B180@datek.no> <63E1BD9318F6470E9B4940C87E775361@gmail.com> <13C53118F617455EAE5256D755589493@gmail.com> Message-ID: <6D0A0E1F-AE4C-4DDB-BFA7-BDF18BF07E55@datek.no> On 2011-05-31, at 18:48, Evan Phoenix wrote: >>>> Thank you for your answer. I thought this might be the right place in case there was a need to define a new platform or OS for RubyGems. >>> You don't need rubygems itself to define a platform, it allows anything and validates it against what ruby -v indicates. >> And if I am on OS X, but want to fetch gems for JRuby or Ruboto, I might use the "--platform java" or "--platform ruboto" options to get the desired gem variants? Can I use both? > Yes, but you should generally not use the rubygems platform specifier to restrict users from using the gem unless it contains platform specific code. So if the gems work fine NOT on android, they should just be normal gems. >>>> 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. > Give it a shot, but we generally don't recommend this path unless there is platform specific code in the gem. For the cases I have in mind, the gems will use the Android API which is platform specific. > If this does work out for you, let us know. I will! Thanks! -- Uwe Kubosch Systems Developer Datek Wireless AS uwe at datek.no http://datek.no/ From evan at fallingsnow.net Tue May 31 18:35:33 2011 From: evan at fallingsnow.net (Evan Phoenix) Date: Tue, 31 May 2011 15:35:33 -0700 Subject: [Rubygems-developers] [ANN] rubygems-update 1.8.5 Released Message-ID: <7CA736DB522E4E9CB63D8DD6B725A5BB@gmail.com> rubygems-update version 1.8.5 has been released! * * * * * RubyGems is a package management framework for Ruby. This gem is an update for the RubyGems software. You must have an installation of RubyGems before this update can be applied. See Gem for information on RubyGems (or `ri Gem`) To upgrade to the latest RubyGems, run: $ gem update --system # you might need to be an administrator or root See UPGRADING.rdoc for more details and alternative instructions. ----- If you don't have RubyGems installed, your can still do it manually: * Download from: https://rubygems.org/pages/download * Unpack into a directory and cd there * Install with: ruby setup.rb # you may need admin/root privilege For more details and other options, see: ruby setup.rb --help Changes: ### 1.8.5 / 2011-05-31 * 2 minor enhancement: * The -u option to 'update local source cache' is official deprecated. * Remove has_rdoc deprecations from Specification. * 2 bug fixes: * Handle bad specs more gracefully. * Reset any Gem paths changed in the installer. From noreply at rubyforge.org Tue May 31 19:26:45 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 31 May 2011 19:26:45 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29169 ] rake creates ruby wrappers around non-ruby executables, causing them to fail Message-ID: <20110531232649.B72861858375@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-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 May 31 19:29:25 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 31 May 2011 19:29:25 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29170 ] with multiple sources, if one is unavailable, nothing works at all Message-ID: <20110531232925.A47631858375@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? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29170&group_id=126 From noreply at rubyforge.org Tue May 31 19:35:54 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 31 May 2011 19:35:54 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29171 ] spork fails to work with rubygems 1.8.0/1.8.1 but works with 1.7.2 Message-ID: <20110531233554.BC0881858375@rubyforge.org> Bugs item #29171, was opened at 2011-05-06 02:30 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29171&group_id=126 Category: None Group: None >Status: Closed >Resolution: Rejected Priority: 3 Submitted By: Bhavin Kamani (beekay) >Assigned to: Ryan Davis (zenspider) Summary: spork fails to work with rubygems 1.8.0/1.8.1 but works with 1.7.2 Initial Comment: After doing a system upgrade spork fails to work with 1.8.0/1.8.1. It appears to be rubygems issue as stacktrace (https://gist.github.com/956888) leads to a rubygem deprecated method "latest_load_paths". All works well when I revert back to 1.7.2 ---------------------------------------------------------------------- >Comment By: Ryan Davis (zenspider) Date: 2011-05-31 16:35 Message: This is done, right? ---------------------------------------------------------------------- Comment By: Tim Harper (timcharper) Date: 2011-05-06 14:38 Message: Well, I feel silly :) Should have read the docs better... find_files is a MUCH better method. I ended up hacking around it by implementing my own latest_load_paths... but yes, find_files is much preferred. Thank you! ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-05-06 14:31 Message: So you're the one! :P I was wondering who used that call. Google codesearch came up with nothing. We don't have any tests on that function so it escaped the wrath of my last cleanup and is apparently currently (inadvertently) broken. We'll get a fix out for it in a bit but in the meantime, I want to address Tim's question about what to use. I don't know why latest_load_paths was added to rubygems, but I wouldn't use it for what you're doing in the first place. Use Gem.find_files instead. It was intended for exactly this purpose. The rdoc for it will point you in the right direction. You'd probably replace your detect_and_require as well as other_spork_gem_load_paths entirely with something like: Gem.find_files('spork/test_framework/*.rb').each do |path| require path end ---------------------------------------------------------------------- Comment By: Tim Harper (timcharper) Date: 2011-05-06 09:33 Message: What can a gem author use in place of latest_load_paths? I'm currently using the method to auto discover peer plug-ins (such as Spork-testunit) and activate code in them. With latest_load_paths removed, it seems that I have to resort to scanning the gem paths myself? That's kind of a bummer, if you ask me. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29171&group_id=126 From noreply at rubyforge.org Tue May 31 19:36:50 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 31 May 2011 19:36:50 -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: <20110531233650.5DAE33C8080@rubyforge.org> Bugs item #29216, was opened at 2011-05-19 14: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: Open >Resolution: Accepted Priority: 3 Submitted By: David Kellum (dekellum) >Assigned to: Ryan Davis (zenspider) >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: Ryan Davis (zenspider) Date: 2011-05-31 16: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 Tue May 31 19:37:34 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 31 May 2011 19:37:34 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29232 ] undefined method `specifications' for "...path":String Message-ID: <20110531233734.3DC831858375@rubyforge.org> Bugs item #29232, was opened at 2011-05-26 17: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: Ryan Davis (zenspider) Date: 2011-05-31 16:37 Message: No repro... c'mon guys... ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-05-28 16: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 16: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 Tue May 31 19:41:05 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 31 May 2011 19:41:05 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29236 ] native extension installation exposes a back door through which gems can be installed with no management Message-ID: <20110531234105.40D621858375@rubyforge.org> Bugs item #29236, was opened at 2011-05-30 06:54 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29236&group_id=126 Category: `gem install` command (extensions) Group: next Status: Open >Resolution: Rejected Priority: 3 Submitted By: David Chelimsky (dchelimsky) >Assigned to: Ryan Davis (zenspider) Summary: native extension installation exposes a back door through which gems can be installed with no management Initial Comment: Per http://rubyforge.org/tracker/?group_id=126&atid=575&func=detail&aid=29229, spork's maintainer used ext/mkrf_conf.rb to install other gems (see https://github.com/timcharper/spork/blob/45675372a2143136705b2ea1b1aa32d420f1caf4/ext/mkrf_conf.rb). This resulted in rake-0.9.0 being installed but it was not reported by the `gem install` command, so we learned about it later. This has been addressed in the spork project, however other projects can still do this. I think this should either be prevented or it should be managed by Rubygems and reported in the output from the `gem install` command. ---------------------------------------------------------------------- >Comment By: Ryan Davis (zenspider) Date: 2011-05-31 16:41 Message: I think this is a simple case where the spork gem shouldn't do that and it is easy enough to work with the authors to find a solution that works for them. ---------------------------------------------------------------------- Comment By: Luis Lavena (luislavena) Date: 2011-05-30 08:40 Message: By nature building extensions is a dangerous process. Before rvm-era, doing gem installation involved 'sudo' elevation. extconf.rb is executed directly from Ruby and actions like FileUtils.rm_rf or shell out to `rm` is also possible. The nature of the extconf configuration and compilation make it hard to run on a sandbox/safe level environment. We end trusting gem authors do the right thing, but the problem is knowing that is right and what is wrong, and that is exposed by the lack of documentation and good practices in relation to this. Nick Quaranto started the RubyGems guides with the aim of educate people: http://guides.rubygems.org/ I suck at copy writing (english or my native spanish) so I leave it the ones that are more verse on it. ---------------------------------------------------------------------- Comment By: Steve Klabnik (steveklabnik) Date: 2011-05-30 08:31 Message: I admittedly am not that knowledgeable about Rubygems' internals, so if you say so. That makes sense, but it also seems complicated and error-prone. While that situation kinda sucked (I was bit by it myself), I'm not sure that any software needs to be written to address this. I'd rather use it as a chance to educate gem developers on best practices, as at worst to 'fix' something like this is a 'gem uninstall rake' away. But I can certainly see the advantages of some kind of warning, too. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2011-05-30 08:27 Message: `gem` is a rubygems command, so rubygems can know when it's being called, even if it's in a separate process (via setting and checking env vars). ---------------------------------------------------------------------- Comment By: Steve Klabnik (steveklabnik) Date: 2011-05-30 07:38 Message: How would one be able to prevent or manage this? mkmf.rb is just a Ruby script, so if it contains a simple `gem install lolz`, it's gonna happen. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29236&group_id=126 From noreply at rubyforge.org Tue May 31 19:44:33 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 31 May 2011 19:44:33 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29236 ] native extension installation exposes a back door through which gems can be installed with no management Message-ID: <20110531234434.0B87A1858375@rubyforge.org> Bugs item #29236, was opened at 2011-05-30 06:54 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29236&group_id=126 Category: `gem install` command (extensions) Group: next >Status: Closed Resolution: Rejected Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: Ryan Davis (zenspider) Summary: native extension installation exposes a back door through which gems can be installed with no management Initial Comment: Per http://rubyforge.org/tracker/?group_id=126&atid=575&func=detail&aid=29229, spork's maintainer used ext/mkrf_conf.rb to install other gems (see https://github.com/timcharper/spork/blob/45675372a2143136705b2ea1b1aa32d420f1caf4/ext/mkrf_conf.rb). This resulted in rake-0.9.0 being installed but it was not reported by the `gem install` command, so we learned about it later. This has been addressed in the spork project, however other projects can still do this. I think this should either be prevented or it should be managed by Rubygems and reported in the output from the `gem install` command. ---------------------------------------------------------------------- >Comment By: Ryan Davis (zenspider) Date: 2011-05-31 16:44 Message: I talked to tenderlove who sent Tim a pull request to change his build/release process entirely and he accepted it. Tim was unaware that you could build platform specific gems and that solves all his issues. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-05-31 16:41 Message: I think this is a simple case where the spork gem shouldn't do that and it is easy enough to work with the authors to find a solution that works for them. ---------------------------------------------------------------------- Comment By: Luis Lavena (luislavena) Date: 2011-05-30 08:40 Message: By nature building extensions is a dangerous process. Before rvm-era, doing gem installation involved 'sudo' elevation. extconf.rb is executed directly from Ruby and actions like FileUtils.rm_rf or shell out to `rm` is also possible. The nature of the extconf configuration and compilation make it hard to run on a sandbox/safe level environment. We end trusting gem authors do the right thing, but the problem is knowing that is right and what is wrong, and that is exposed by the lack of documentation and good practices in relation to this. Nick Quaranto started the RubyGems guides with the aim of educate people: http://guides.rubygems.org/ I suck at copy writing (english or my native spanish) so I leave it the ones that are more verse on it. ---------------------------------------------------------------------- Comment By: Steve Klabnik (steveklabnik) Date: 2011-05-30 08:31 Message: I admittedly am not that knowledgeable about Rubygems' internals, so if you say so. That makes sense, but it also seems complicated and error-prone. While that situation kinda sucked (I was bit by it myself), I'm not sure that any software needs to be written to address this. I'd rather use it as a chance to educate gem developers on best practices, as at worst to 'fix' something like this is a 'gem uninstall rake' away. But I can certainly see the advantages of some kind of warning, too. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2011-05-30 08:27 Message: `gem` is a rubygems command, so rubygems can know when it's being called, even if it's in a separate process (via setting and checking env vars). ---------------------------------------------------------------------- Comment By: Steve Klabnik (steveklabnik) Date: 2011-05-30 07:38 Message: How would one be able to prevent or manage this? mkmf.rb is just a Ruby script, so if it contains a simple `gem install lolz`, it's gonna happen. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29236&group_id=126 From noreply at rubyforge.org Tue May 31 19:57:39 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 31 May 2011 19:57:39 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29141 ] Uninstaller fails when format-executable is set Message-ID: <20110531235739.A1C5A1858377@rubyforge.org> Bugs item #29141, was opened at 2011-04-21 08:12 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29141&group_id=126 Category: `gem` commands (other) Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Sakuro OZAWA (sakuro) >Assigned to: Ryan Davis (zenspider) Summary: Uninstaller fails when format-executable is set Initial Comment: When format-executable is set, uninstaller calls Gem::Installer.exec_format but the class is not defined. $ gem uninstall nokogiri # in my case, --format-executable is set in .gemrc Remove executables: nokogiri in addition to the gem? [Yn] y Removing nokogiri ERROR: While executing gem ... (NameError) uninitialized constant Gem::Installer /usr/local/lib/ruby/site_ruby/1.9.1/rubygems/uninstaller.rb:264:in `formatted_program_filename' $ ruby -v ruby 1.9.3dev (2011-04-21 trunk 31316) [x86_64-darwin10.7.0] $ gem -v 1.7.2 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29141&group_id=126 From noreply at rubyforge.org Tue May 31 20:11:41 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 31 May 2011 20:11:41 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29124 ] bad spec in ~/.gem/specs should be redownloaded instead of crashing Message-ID: <20110601001142.0B8D41858377@rubyforge.org> Bugs item #29124, was opened at 2011-04-11 17:21 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29124&group_id=126 >Category: `gem install` command Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Ryan Cook (cookrn) >Assigned to: Ryan Davis (zenspider) Summary: bad spec in ~/.gem/specs should be redownloaded instead of crashing Initial Comment: command: "gem install thin" backtrace: https://gist.github.com/914642#file_trace.rb env: https://gist.github.com/914642#file_env.rb solution: running "gem sources -c" then re-running "gem install thin" ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29124&group_id=126 From noreply at rubyforge.org Tue May 31 20:20:42 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 31 May 2011 20:20:42 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29188 ] rails 2.3.11 fails to load with rubygems 1.8.1 Message-ID: <20110601002042.D2CBD1858372@rubyforge.org> Bugs item #29188, was opened at 2011-05-08 12:33 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29188&group_id=126 Category: other Group: None >Status: Closed Resolution: Rejected Priority: 3 Submitted By: Greg Hazel (ghazel) Assigned to: Ryan Davis (zenspider) Summary: rails 2.3.11 fails to load with rubygems 1.8.1 Initial Comment: Upgraded from 1.7.2 to 1.8.1, then a Rails 2.3.11 app failed to load: /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/gems/1.8/gems/rails-2.3.11/lib/rails/gem_dependency.rb:277:in `==': undefined method `name' for "POpen4":String (NoMethodError) from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/site_ruby/1.8/rubygems/dependency.rb:217:in `===' from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/site_ruby/1.8/rubygems/dependency.rb:217:in `matching_specs' from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/site_ruby/1.8/rubygems/specification.rb:539:in `find_all' from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/site_ruby/1.8/rubygems/specification.rb:403:in `each' from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/site_ruby/1.8/rubygems/specification.rb:402:in `each' from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/site_ruby/1.8/rubygems/dependency.rb:216:in `find_all' from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/site_ruby/1.8/rubygems/dependency.rb:216:in `matching_specs' from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/site_ruby/1.8/rubygems/dependency.rb:238:in `to_specs' from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/site_ruby/1.8/rubygems/dependency.rb:256:in `to_spec' from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/site_ruby/1.8/rubygems.rb:1182:in `gem' from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/gems/1.8/gems/rails-2.3.11/lib/rails/gem_dependency.rb:75:in `add_load_paths' from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/gems/1.8/gems/rails-2.3.11/lib/initializer.rb:301:in `add_gem_load_paths' from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/gems/1.8/gems/rails-2.3.11/lib/initializer.rb:301:in `each' from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/gems/1.8/gems/rails-2.3.11/lib/initializer.rb:301:in `add_gem_load_paths' from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/gems/1.8/gems/rails-2.3.11/lib/initializer.rb:132:in `process' from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/gems/1.8/gems/rails-2.3.11/lib/initializer.rb:113:in `send' from /usr/local/ruby-enterprise-1.8.7-2010.01/lib/ruby/gems/1.8/gems/rails-2.3.11/lib/initializer.rb:113:in `run' ---------------------------------------------------------------------- >Comment By: Ryan Davis (zenspider) Date: 2011-05-31 17:20 Message: This is a rails issue and should be addressed in 2.3.12. ---------------------------------------------------------------------- Comment By: etienne massip (emassip) Date: 2011-05-20 11:53 Message: BTW, looks like an Rails incompatibility issue. ---------------------------------------------------------------------- Comment By: etienne massip (emassip) Date: 2011-05-20 07:21 Message: Got same issue in Redmine with Rails 2.3.11 and latests RubyGems versions, see http://www.redmine.org/issues/8325. ---------------------------------------------------------------------- Comment By: Roger Pack (rogerdpack) Date: 2011-05-13 14:01 Message: Just ran into this, too. http://betterlogic.com/roger/2011/05/undefined-method/ ---------------------------------------------------------------------- Comment By: Greg Hazel (ghazel) Date: 2011-05-12 09:23 Message: The first Rubygems commit where this error is reproducible is: https://github.com/rubygems/rubygems/commit/97932d63efbd35704c1669ea281a4701fe2ecb60 Although before that a different error is encountered, which started with this commit: https://github.com/rubygems/rubygems/commit/78a43480440f527c22452e1ae986206712959ef5 ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-05-11 20:32 Message: Cleaned up path that works in my rubygems checkout: rails-2.3.11/lib/rails/gem_dependency.rb:277:in `==': undefined method `name' for "POpen4":String (NoMethodError) from lib/rubygems/dependency.rb:217:in `===' from lib/rubygems/dependency.rb:217:in `matching_specs' from lib/rubygems/specification.rb:539:in `find_all' from lib/rubygems/specification.rb:403:in `each' from lib/rubygems/specification.rb:402:in `each' from lib/rubygems/dependency.rb:216:in `find_all' from lib/rubygems/dependency.rb:216:in `matching_specs' from lib/rubygems/dependency.rb:238:in `to_specs' from lib/rubygems/dependency.rb:256:in `to_spec' from lib/rubygems.rb:1182:in `gem' from rails-2.3.11/lib/rails/gem_dependency.rb:75:in `add_load_paths' from rails-2.3.11/lib/initializer.rb:301:in `add_gem_load_paths' from rails-2.3.11/lib/initializer.rb:301:in `each' from rails-2.3.11/lib/initializer.rb:301:in `add_gem_load_paths' from rails-2.3.11/lib/initializer.rb:132:in `process' from rails-2.3.11/lib/initializer.rb:113:in `send' from rails-2.3.11/lib/initializer.rb:113:in `run' gem_dependency.rb:277 is a buggy impl of #==: def ==(other) self.name == other.name && self.requirement == other.requirement end It's simply bad form to not check the class first. Not sure how that ever passed code review. That alone would probably fix the issue, but I'm not sure as I can't tell you why their call of #name returns another dep. Couple that with a very sketchy implementation: def add_load_paths self.class.add_frozen_gem_path return if @loaded || @load_paths_added if framework_gem? @load_paths_added = @loaded = @frozen = true return end gem self @spec = Gem.loaded_specs[name] @frozen = @spec.loaded_from.include?(self.class.unpacked_path) if @spec @load_paths_added = true rescue Gem::LoadError end `gem self` where self is a GemDependency (a subclass of our Gem::Dependency) just doesn't make sense. I'm not sure how this ever worked and it is possible it never did given that completely blithe rescue at the bottom... ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29188&group_id=126 From noreply at rubyforge.org Tue May 31 20:22:26 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 31 May 2011 20:22:26 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29236 ] native extension installation exposes a back door through which gems can be installed with no management Message-ID: <20110601002226.6E2581858372@rubyforge.org> Bugs item #29236, was opened at 2011-05-30 13:54 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29236&group_id=126 Category: `gem install` command (extensions) Group: next Status: Closed Resolution: Rejected Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: Ryan Davis (zenspider) Summary: native extension installation exposes a back door through which gems can be installed with no management Initial Comment: Per http://rubyforge.org/tracker/?group_id=126&atid=575&func=detail&aid=29229, spork's maintainer used ext/mkrf_conf.rb to install other gems (see https://github.com/timcharper/spork/blob/45675372a2143136705b2ea1b1aa32d420f1caf4/ext/mkrf_conf.rb). This resulted in rake-0.9.0 being installed but it was not reported by the `gem install` command, so we learned about it later. This has been addressed in the spork project, however other projects can still do this. I think this should either be prevented or it should be managed by Rubygems and reported in the output from the `gem install` command. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2011-06-01 00:22 Message: This isn't really about spork. It was easy enough to work with spork's maintainer once we figured out it was spork, but narrowing that down took no small effort. My concern is that somebody will do this again in the future and some other team will incur that cost again. I'm not worried about my team incurring that cost because we'll know what to look for :) I'm not going to press on this, but I just wanted to document the wider context. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-05-31 23:44 Message: I talked to tenderlove who sent Tim a pull request to change his build/release process entirely and he accepted it. Tim was unaware that you could build platform specific gems and that solves all his issues. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-05-31 23:41 Message: I think this is a simple case where the spork gem shouldn't do that and it is easy enough to work with the authors to find a solution that works for them. ---------------------------------------------------------------------- Comment By: Luis Lavena (luislavena) Date: 2011-05-30 15:40 Message: By nature building extensions is a dangerous process. Before rvm-era, doing gem installation involved 'sudo' elevation. extconf.rb is executed directly from Ruby and actions like FileUtils.rm_rf or shell out to `rm` is also possible. The nature of the extconf configuration and compilation make it hard to run on a sandbox/safe level environment. We end trusting gem authors do the right thing, but the problem is knowing that is right and what is wrong, and that is exposed by the lack of documentation and good practices in relation to this. Nick Quaranto started the RubyGems guides with the aim of educate people: http://guides.rubygems.org/ I suck at copy writing (english or my native spanish) so I leave it the ones that are more verse on it. ---------------------------------------------------------------------- Comment By: Steve Klabnik (steveklabnik) Date: 2011-05-30 15:31 Message: I admittedly am not that knowledgeable about Rubygems' internals, so if you say so. That makes sense, but it also seems complicated and error-prone. While that situation kinda sucked (I was bit by it myself), I'm not sure that any software needs to be written to address this. I'd rather use it as a chance to educate gem developers on best practices, as at worst to 'fix' something like this is a 'gem uninstall rake' away. But I can certainly see the advantages of some kind of warning, too. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2011-05-30 15:27 Message: `gem` is a rubygems command, so rubygems can know when it's being called, even if it's in a separate process (via setting and checking env vars). ---------------------------------------------------------------------- Comment By: Steve Klabnik (steveklabnik) Date: 2011-05-30 14:38 Message: How would one be able to prevent or manage this? mkmf.rb is just a Ruby script, so if it contains a simple `gem install lolz`, it's gonna happen. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29236&group_id=126 From noreply at rubyforge.org Tue May 31 20:38:49 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 31 May 2011 20:38:49 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29236 ] native extension installation exposes a back door through which gems can be installed with no management Message-ID: <20110601003849.6ACD3185836C@rubyforge.org> Bugs item #29236, was opened at 2011-05-30 13:54 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29236&group_id=126 Category: `gem install` command (extensions) Group: next Status: Closed Resolution: Rejected Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: Ryan Davis (zenspider) Summary: native extension installation exposes a back door through which gems can be installed with no management Initial Comment: Per http://rubyforge.org/tracker/?group_id=126&atid=575&func=detail&aid=29229, spork's maintainer used ext/mkrf_conf.rb to install other gems (see https://github.com/timcharper/spork/blob/45675372a2143136705b2ea1b1aa32d420f1caf4/ext/mkrf_conf.rb). This resulted in rake-0.9.0 being installed but it was not reported by the `gem install` command, so we learned about it later. This has been addressed in the spork project, however other projects can still do this. I think this should either be prevented or it should be managed by Rubygems and reported in the output from the `gem install` command. ---------------------------------------------------------------------- >Comment By: Evan Phoenix (evan) Date: 2011-06-01 00:38 Message: The issue is largely a question of how would rubygems limit what a gem can do to build it's extension. The only primary thing we could do would be to pass an environment variable down which would say "you're building an extension now" so that gem could bail out in this case. But that would largely only protect people who did it accidentally and not those who are doing it maliciously (since they could simply remove the env var first). Do you think only have it exist as an advisement is good enough? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2011-06-01 00:22 Message: This isn't really about spork. It was easy enough to work with spork's maintainer once we figured out it was spork, but narrowing that down took no small effort. My concern is that somebody will do this again in the future and some other team will incur that cost again. I'm not worried about my team incurring that cost because we'll know what to look for :) I'm not going to press on this, but I just wanted to document the wider context. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-05-31 23:44 Message: I talked to tenderlove who sent Tim a pull request to change his build/release process entirely and he accepted it. Tim was unaware that you could build platform specific gems and that solves all his issues. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-05-31 23:41 Message: I think this is a simple case where the spork gem shouldn't do that and it is easy enough to work with the authors to find a solution that works for them. ---------------------------------------------------------------------- Comment By: Luis Lavena (luislavena) Date: 2011-05-30 15:40 Message: By nature building extensions is a dangerous process. Before rvm-era, doing gem installation involved 'sudo' elevation. extconf.rb is executed directly from Ruby and actions like FileUtils.rm_rf or shell out to `rm` is also possible. The nature of the extconf configuration and compilation make it hard to run on a sandbox/safe level environment. We end trusting gem authors do the right thing, but the problem is knowing that is right and what is wrong, and that is exposed by the lack of documentation and good practices in relation to this. Nick Quaranto started the RubyGems guides with the aim of educate people: http://guides.rubygems.org/ I suck at copy writing (english or my native spanish) so I leave it the ones that are more verse on it. ---------------------------------------------------------------------- Comment By: Steve Klabnik (steveklabnik) Date: 2011-05-30 15:31 Message: I admittedly am not that knowledgeable about Rubygems' internals, so if you say so. That makes sense, but it also seems complicated and error-prone. While that situation kinda sucked (I was bit by it myself), I'm not sure that any software needs to be written to address this. I'd rather use it as a chance to educate gem developers on best practices, as at worst to 'fix' something like this is a 'gem uninstall rake' away. But I can certainly see the advantages of some kind of warning, too. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2011-05-30 15:27 Message: `gem` is a rubygems command, so rubygems can know when it's being called, even if it's in a separate process (via setting and checking env vars). ---------------------------------------------------------------------- Comment By: Steve Klabnik (steveklabnik) Date: 2011-05-30 14:38 Message: How would one be able to prevent or manage this? mkmf.rb is just a Ruby script, so if it contains a simple `gem install lolz`, it's gonna happen. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29236&group_id=126 From noreply at rubyforge.org Tue May 31 21:01:40 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 31 May 2011 21:01:40 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29236 ] native extension installation exposes a back door through which gems can be installed with no management Message-ID: <20110601010142.09ED2185836C@rubyforge.org> Bugs item #29236, was opened at 2011-05-30 13:54 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29236&group_id=126 Category: `gem install` command (extensions) Group: next Status: Closed Resolution: Rejected Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: Ryan Davis (zenspider) Summary: native extension installation exposes a back door through which gems can be installed with no management Initial Comment: Per http://rubyforge.org/tracker/?group_id=126&atid=575&func=detail&aid=29229, spork's maintainer used ext/mkrf_conf.rb to install other gems (see https://github.com/timcharper/spork/blob/45675372a2143136705b2ea1b1aa32d420f1caf4/ext/mkrf_conf.rb). This resulted in rake-0.9.0 being installed but it was not reported by the `gem install` command, so we learned about it later. This has been addressed in the spork project, however other projects can still do this. I think this should either be prevented or it should be managed by Rubygems and reported in the output from the `gem install` command. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2011-06-01 01:01 Message: What I think is only what I think. I'm not saying it's right. I'm not sure whether preventing it or reporting it would be the better choice, were we to implement a programmatic solution. In our case, seeing a message saying "installing rake-0.9.0" would have saved the hair of a small herd of yaks. That said, if the docs on mkrf_conf.rb are loud and clear and in a place that people will look and find them, it seems like overkill at that point to then put a programmatic solution in place as well. Also, totally agree that a programmatic solution wouldn't solve the problem of maliciousness. I say leave it be, document it, and if it happens again we can revisit. ---------------------------------------------------------------------- Comment By: Evan Phoenix (evan) Date: 2011-06-01 00:38 Message: The issue is largely a question of how would rubygems limit what a gem can do to build it's extension. The only primary thing we could do would be to pass an environment variable down which would say "you're building an extension now" so that gem could bail out in this case. But that would largely only protect people who did it accidentally and not those who are doing it maliciously (since they could simply remove the env var first). Do you think only have it exist as an advisement is good enough? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2011-06-01 00:22 Message: This isn't really about spork. It was easy enough to work with spork's maintainer once we figured out it was spork, but narrowing that down took no small effort. My concern is that somebody will do this again in the future and some other team will incur that cost again. I'm not worried about my team incurring that cost because we'll know what to look for :) I'm not going to press on this, but I just wanted to document the wider context. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-05-31 23:44 Message: I talked to tenderlove who sent Tim a pull request to change his build/release process entirely and he accepted it. Tim was unaware that you could build platform specific gems and that solves all his issues. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-05-31 23:41 Message: I think this is a simple case where the spork gem shouldn't do that and it is easy enough to work with the authors to find a solution that works for them. ---------------------------------------------------------------------- Comment By: Luis Lavena (luislavena) Date: 2011-05-30 15:40 Message: By nature building extensions is a dangerous process. Before rvm-era, doing gem installation involved 'sudo' elevation. extconf.rb is executed directly from Ruby and actions like FileUtils.rm_rf or shell out to `rm` is also possible. The nature of the extconf configuration and compilation make it hard to run on a sandbox/safe level environment. We end trusting gem authors do the right thing, but the problem is knowing that is right and what is wrong, and that is exposed by the lack of documentation and good practices in relation to this. Nick Quaranto started the RubyGems guides with the aim of educate people: http://guides.rubygems.org/ I suck at copy writing (english or my native spanish) so I leave it the ones that are more verse on it. ---------------------------------------------------------------------- Comment By: Steve Klabnik (steveklabnik) Date: 2011-05-30 15:31 Message: I admittedly am not that knowledgeable about Rubygems' internals, so if you say so. That makes sense, but it also seems complicated and error-prone. While that situation kinda sucked (I was bit by it myself), I'm not sure that any software needs to be written to address this. I'd rather use it as a chance to educate gem developers on best practices, as at worst to 'fix' something like this is a 'gem uninstall rake' away. But I can certainly see the advantages of some kind of warning, too. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2011-05-30 15:27 Message: `gem` is a rubygems command, so rubygems can know when it's being called, even if it's in a separate process (via setting and checking env vars). ---------------------------------------------------------------------- Comment By: Steve Klabnik (steveklabnik) Date: 2011-05-30 14:38 Message: How would one be able to prevent or manage this? mkmf.rb is just a Ruby script, so if it contains a simple `gem install lolz`, it's gonna happen. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29236&group_id=126 From noreply at rubyforge.org Tue May 31 22:50:50 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 31 May 2011 22:50:50 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-26109 ] gem install gemname --remote will fail if gemname is in current directory Message-ID: <20110601025051.22DFF1858375@rubyforge.org> Bugs item #26109, was opened at 2009-06-02 22:03 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=26109&group_id=126 Category: `gem install` command Group: None >Status: Closed Resolution: None Priority: 3 Submitted By: ara howard (ahoward) >Assigned to: Evan Phoenix (evan) Summary: gem install gemname --remote will fail if gemname is in current directory Initial Comment: gem install gemname --remote will prefer a gem in the current directory. seems like --remote should *never* do *anything* local? ---------------------------------------------------------------------- >Comment By: Evan Phoenix (evan) Date: 2011-06-01 02:50 Message: Fixed in github:fe493ea ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2010-12-17 10:19 Message: Thanks Asari. Seems valid to me. Assigning to JB and leaving this one open since it also talks about local cache and there might be extra edge cases here. ---------------------------------------------------------------------- Comment By: Hirotsugu Asari (asarih) Date: 2010-12-17 06:35 Message: Ryan, Could this other ticket help your reproduce it? http://rubyforge.org/tracker/index.php?func=detail&aid=28481&group_id=126&atid=575 Also, `gem install` appears to search the local cache before querying remote sources, so if foo-1.0.0.dev1.gem exists in cache, it will be chosen, even when foo-1.0.0.gem (with seemingly more recent version number) is available on a remote server. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2010-11-12 22:46 Message: This ticket has been deemed stale and we're closing it in order to catch up with our ticket list. If you think it is still valid, please reopen. ---------------------------------------------------------------------- Comment By: Christof Spies (wingfire) Date: 2010-08-20 06:52 Message: gem env RubyGems Environment: - RUBYGEMS VERSION: 1.3.7 - RUBY VERSION: 1.8.7 (2008-08-11 patchlevel 72) [x86_64-linux] - INSTALLATION DIRECTORY: /usr/lib/ruby/gems/1.8 - RUBY EXECUTABLE: /usr/bin/ruby1.8 - EXECUTABLE DIRECTORY: /usr/bin - RUBYGEMS PLATFORMS: - ruby - x86_64-linux - GEM PATHS: - /usr/lib/ruby/gems/1.8 - /root/.gem/ruby/1.8 - GEM CONFIGURATION: - :update_sources => true - :verbose => true - :benchmark => false - :backtrace => false - :bulk_threshold => 1000 - REMOTE SOURCES: - http://rubygems.org/ ---------------------------------------------------------------------- Comment By: Christof Spies (wingfire) Date: 2010-08-20 06:47 Message: I can confirm this issue. i.e. you have an outdated gem file in your home directory and run "gem update" from home then gem reinstall the old gem from the home directory. "gem update -r" is also "updating" with the outdated local gem. ---------------------------------------------------------------------- Comment By: Nick Hildebrant (nihildeb) Date: 2009-08-27 22:37 Message: Just familiarizing myself with the code here. I now see the issue. #find_gems_with_sources probably should only merge gem sources if @domain == :both also I don't see a case in which setting @domain = :local after rescuing a RemoteFetch exception would be useful or make sense ---------------------------------------------------------------------- Comment By: Nick Hildebrant (nihildeb) Date: 2009-08-26 20:54 Message: I can not reproduce this issue as a "preference". Rubygems appears to do remote as requested with requested gem in pwd. In the case of no network availability, the requested gem in the pwd is installed. This is as designed: Gem::DependencyInstaller#find_gems_with_sources rescues with @domain = :local RubyGems Environment: - RUBYGEMS VERSION: 1.3.3 - RUBY VERSION: 1.8.7 (2009-06-12 patchlevel 174) [x86_64-linux] - INSTALLATION DIRECTORY: /usr/lib/ruby/gems/1.8 - RUBY EXECUTABLE: /usr/bin/ruby - EXECUTABLE DIRECTORY: /usr/bin - RUBYGEMS PLATFORMS: - ruby - x86_64-linux - GEM PATHS: - /usr/lib/ruby/gems/1.8 - /home/nihildeb/.gem/ruby/1.8 - GEM CONFIGURATION: - :update_sources => true - :verbose => true - :benchmark => false - :backtrace => false - :bulk_threshold => 1000 - :sources => ["http://gems.rubyforge.org", "http://gems.github.com"] - REMOTE SOURCES: - http://gems.rubyforge.org - http://gems.github.com ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=26109&group_id=126 From noreply at rubyforge.org Tue May 31 23:40:24 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 31 May 2011 23:40:24 -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: <20110601034024.E472C1858361@rubyforge.org> Bugs item #29216, was opened at 2011-05-19 14: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: Open Resolution: Accepted Priority: 3 Submitted By: David Kellum (dekellum) Assigned to: Ryan Davis (zenspider) >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: David Kellum (dekellum) Date: 2011-05-31 20:40 Message: Pull request is here: https://github.com/rubygems/rubygems/pull/62 Thanks. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-05-31 16: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