From ryand-ruby at zenspider.com Fri Apr 1 00:31:00 2011 From: ryand-ruby at zenspider.com (Ryan Davis) Date: Thu, 31 Mar 2011 21:31:00 -0700 Subject: [Rubygems-developers] 1.7 is ready Message-ID: <5158F26B-29C7-4A0A-8723-259568C158C9@zenspider.com> I got the last of my changes in and it is ready for release. I don't think Eric is available to release it tonight, so it'll go out on the 32nd of March. I didn't get all the changes in that I wanted to get in, mostly due to time constraints but also because the API is so big and hairy. I did get a deprecation module in and deprecated 16 different methods (and cleaned up internal and test usage of them)! So... that's something. We're gonna remove the methods 6 months from now. From evan at fallingsnow.net Fri Apr 1 00:44:43 2011 From: evan at fallingsnow.net (Evan Phoenix) Date: Thu, 31 Mar 2011 21:44:43 -0700 Subject: [Rubygems-developers] 1.7 is ready In-Reply-To: <5158F26B-29C7-4A0A-8723-259568C158C9@zenspider.com> References: <5158F26B-29C7-4A0A-8723-259568C158C9@zenspider.com> Message-ID: <47EB1502-F45D-4C7A-A986-8FA78C7BDA80@fallingsnow.net> On Mar 31, 2011, at 9:31 PM, Ryan Davis wrote: > I got the last of my changes in and it is ready for release. I don't think Eric is available to release it tonight, so it'll go out on the 32nd of March. Sounds good! > > I didn't get all the changes in that I wanted to get in, mostly due to time constraints but also because the API is so big and hairy. I did get a deprecation module in and deprecated 16 different methods (and cleaned up internal and test usage of them)! So... that's something. We're gonna remove the methods 6 months from now. Super glad to hear that we've got an official way to deprecate now. Thanks! I've got a minor issue. The changes pushed this evening have broken the bundler tests (http://bundler.indirect.name/job/bundler-1-0-vs-rubygems-master/). Could I have at least tomorrow morning to sort this out before the release? - Evan > > _______________________________________________ > Rubygems-developers mailing list > http://rubyforge.org/projects/rubygems > Rubygems-developers at rubyforge.org > http://rubyforge.org/mailman/listinfo/rubygems-developers > From evan at fallingsnow.net Fri Apr 1 01:02:37 2011 From: evan at fallingsnow.net (Evan Phoenix) Date: Thu, 31 Mar 2011 22:02:37 -0700 Subject: [Rubygems-developers] 1.7 is ready In-Reply-To: <47EB1502-F45D-4C7A-A986-8FA78C7BDA80@fallingsnow.net> References: <5158F26B-29C7-4A0A-8723-259568C158C9@zenspider.com> <47EB1502-F45D-4C7A-A986-8FA78C7BDA80@fallingsnow.net> Message-ID: <3E1966B5-74D9-489A-8C58-D63FC965DFF9@fallingsnow.net> See below. On Mar 31, 2011, at 9:44 PM, Evan Phoenix wrote: > > On Mar 31, 2011, at 9:31 PM, Ryan Davis wrote: > >> I got the last of my changes in and it is ready for release. I don't think Eric is available to release it tonight, so it'll go out on the 32nd of March. > > Sounds good! > >> >> I didn't get all the changes in that I wanted to get in, mostly due to time constraints but also because the API is so big and hairy. I did get a deprecation module in and deprecated 16 different methods (and cleaned up internal and test usage of them)! So... that's something. We're gonna remove the methods 6 months from now. > > Super glad to hear that we've got an official way to deprecate now. Thanks! > > I've got a minor issue. The changes pushed this evening have broken the bundler tests (http://bundler.indirect.name/job/bundler-1-0-vs-rubygems-master/). Could I have at least tomorrow morning to sort this out before the release? I've reviewed you're changes and the bundler breakages. Your removal of using from_gems_in has broken bundlers hack for how it advertises it's static set of gemspecs to the system. While I understand you do not believe that it's worth allowing bundler to hack on the internals, please allow me and the bundler team at least a day to figure out how to fix bundler to work with this newest version of rubygems. > > - Evan > >> >> _______________________________________________ >> Rubygems-developers mailing list >> http://rubyforge.org/projects/rubygems >> Rubygems-developers at rubyforge.org >> http://rubyforge.org/mailman/listinfo/rubygems-developers >> > > _______________________________________________ > Rubygems-developers mailing list > http://rubyforge.org/projects/rubygems > Rubygems-developers at rubyforge.org > http://rubyforge.org/mailman/listinfo/rubygems-developers > From luislavena at gmail.com Fri Apr 1 07:34:39 2011 From: luislavena at gmail.com (Luis Lavena) Date: Fri, 1 Apr 2011 08:34:39 -0300 Subject: [Rubygems-developers] 1.7 is ready In-Reply-To: <5158F26B-29C7-4A0A-8723-259568C158C9@zenspider.com> References: <5158F26B-29C7-4A0A-8723-259568C158C9@zenspider.com> Message-ID: I will check everything today's morning. Sent from mobile. On Apr 1, 2011 1:39 AM, "Ryan Davis" wrote: > I got the last of my changes in and it is ready for release. I don't think Eric is available to release it tonight, so it'll go out on the 32nd of March. > > I didn't get all the changes in that I wanted to get in, mostly due to time constraints but also because the API is so big and hairy. I did get a deprecation module in and deprecated 16 different methods (and cleaned up internal and test usage of them)! So... that's something. We're gonna remove the methods 6 months from now. > > _______________________________________________ > 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 Fri Apr 1 04:24:04 2011 From: ryand-ruby at zenspider.com (Ryan Davis) Date: Fri, 1 Apr 2011 01:24:04 -0700 Subject: [Rubygems-developers] 1.7 is ready In-Reply-To: <47EB1502-F45D-4C7A-A986-8FA78C7BDA80@fallingsnow.net> References: <5158F26B-29C7-4A0A-8723-259568C158C9@zenspider.com> <47EB1502-F45D-4C7A-A986-8FA78C7BDA80@fallingsnow.net> Message-ID: On Mar 31, 2011, at 21:44 , Evan Phoenix wrote: > > On Mar 31, 2011, at 9:31 PM, Ryan Davis wrote: > >> I got the last of my changes in and it is ready for release. I don't think Eric is available to release it tonight, so it'll go out on the 32nd of March. > > Sounds good! > >> >> I didn't get all the changes in that I wanted to get in, mostly due to time constraints but also because the API is so big and hairy. I did get a deprecation module in and deprecated 16 different methods (and cleaned up internal and test usage of them)! So... that's something. We're gonna remove the methods 6 months from now. > > Super glad to hear that we've got an official way to deprecate now. Thanks! > > I've got a minor issue. The changes pushed this evening have broken the bundler tests (http://bundler.indirect.name/job/bundler-1-0-vs-rubygems-master/). Could I have at least tomorrow morning to sort this out before the release? I don't do mornings, so: sure! :P I tried to look through the specs to see what might be wrong... and well... I can't read their code at all... I gave up. From drbrain at segment7.net Fri Apr 1 17:16:48 2011 From: drbrain at segment7.net (Eric Hodel) Date: Fri, 1 Apr 2011 14:16:48 -0700 Subject: [Rubygems-developers] [ANN] RubyGems 1.7.0 Message-ID: <42003515-61EF-4096-AECC-A1BAEAB83E09@segment7.net> rubygems-update version 1.7.0 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. == GETTING HELP === Support Requests Are you unsure of how to use RubyGems? Do you think you've found a bug and you're not sure? If that is the case, the best place for you is to file a support request at {help.rubygems.org}[http://help.rubygems.org]. === Filing Tickets You're sure you've found a bug! But where do you let us know? The best place for letting the RubyGems team know about bugs you've found is {on the rubygems tracker at rubyforge}[http://rubyforge.org/tracker/?group_id=126]. === Bundler Compatibility See http://gembundler.com/compatibility for known issues. ----- 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.7.0 / 2011-03-32 * 16 Deprecations (woot!) * Deprecated Gem.all_load_paths, latest_load_paths, promote_load_path, and cache. * Deprecated RemoteFetcher#open_uri_or_path. * Deprecated SourceIndex#all_gems. * Deprecated SourceIndex#initialize(hash_of_specs). * Deprecated SourceIndex.from_installed_gems, from_gems_in, and load_specification. * Deprecated Specification#has_rdoc, default_executable, and test_suite_file(=). * Deprecated Specification#has_rdoc= and default_executable= * 26 minor enhancements: * Added stupid simple deprecation module. * Added --spec option to `gem unpack` to output a gem's original metadata * Added packaging option to Specification#validate * Gem.bin_path requires the exec_name argument. * Read from cached specs if fetch fails for some reason * Refactored Specification#assign_defaults into #initialize. * RemoteFetcher#fetch_path now dispatches dynamically to 'fetch_' * Removed Specification @@gather. * Removed Specification.attribute. * Removed Specification.attribute_alias_singular. * Removed Specification.attribute_defaults. * Removed Specification.attributes * Removed Specification.overwrite_accessor. * Removed Specification.read_only. * Removed Specification.required_attribute. * Removed Specification::SPECIFICATION_VERSION_HISTORY and turned into rdoc * Removed blanket rescue in default_executable. Hope it doesn't blow up! :P * Removed nearly all metaprogramming from Specification. Yay for attr_accessor! * SourceIndex#initialize changed to prefer an array of spec dirs, defaulting to none. * SourceIndex.new is now the preferred way to create SourceIndex instances. *gasp* * Specification#validate now checks that array attribs are indeed arrays. * Specification.default_value is now an instance method. * Switched Specification::TODAY to be proper midnight @ UTC * Update Gem::RemoteFetcher\'s User-Agent to handle RUBY_ENGINE and RUBY_REVISION when patchlevel is -1 * UpdateCommand#gems_to_update now returns (name, version) pairs. * UpdateCommand#which_to_update now takes an optional system argument. * 11 bug fixes: * Added missing remote fetcher require to pristine command (aarnell) * Building gems now checks to ensure all required fields are non-nil * Fix option parser when summary is nil. * Fixed `gem contents` to work with the lightweight specifications * Fixed `gem update --system x.y.z` where x.y.z == latest version. (MGPalmer) * Fixed gem contents sorting and tests. (MGPalmer) * Fixed intermittant problem in `gem fetch` with --platform specified (quix) * Fixed lightweight specifications so `gem rdoc` will generate proper documentation * MockGemUI#terminate_interaction should not raise Gem::SystemExitException. (MGPalmer) * RubyGems now raises a better error for broken .gem files. Bug #29067 by Elias Baixas * `gem update` now uniq's command line arguments. From drbrain at segment7.net Fri Apr 1 18:57:30 2011 From: drbrain at segment7.net (Eric Hodel) Date: Fri, 1 Apr 2011 15:57:30 -0700 Subject: [Rubygems-developers] [ANN] rubygems 1.7.1 Message-ID: <3209DC3F-64D7-4899-AC65-D9886D9F4583@segment7.net> After much finger-pointing, rubygems-update version 1.7.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. === GETTING HELP === Support Requests Are you unsure of how to use RubyGems? Do you think you've found a bug and you're not sure? If that is the case, the best place for you is to file a support request at {help.rubygems.org}[http://help.rubygems.org]. === Filing Tickets You're sure you've found a bug! But where do you let us know? The best place for letting the RubyGems team know about bugs you've found is {on the rubygems tracker at rubyforge}[http://rubyforge.org/tracker/?group_id=126]. === Bundler Compatibility See http://gembundler.com/compatibility for known issues. ----- 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.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.) === 1.7.0 / 2011-03-32 * 16 Deprecations (woot!) * Deprecated Gem.all_load_paths, latest_load_paths, promote_load_path, and cache. * Deprecated RemoteFetcher#open_uri_or_path. * Deprecated SourceIndex#all_gems. * Deprecated SourceIndex#initialize(hash_of_specs). * Deprecated SourceIndex.from_installed_gems, from_gems_in, and load_specification. * Deprecated Specification#has_rdoc, default_executable, and test_suite_file(=). * Deprecated Specification#has_rdoc= and default_executable= * 26 minor enhancements: * Added stupid simple deprecation module. * Added --spec option to `gem unpack` to output a gem's original metadata * Added packaging option to Specification#validate * Gem.bin_path requires the exec_name argument. * Read from cached specs if fetch fails for some reason * Refactored Specification#assign_defaults into #initialize. * RemoteFetcher#fetch_path now dispatches dynamically to 'fetch_' * Removed Specification @@gather. * Removed Specification.attribute. * Removed Specification.attribute_alias_singular. * Removed Specification.attribute_defaults. * Removed Specification.attributes * Removed Specification.overwrite_accessor. * Removed Specification.read_only. * Removed Specification.required_attribute. * Removed Specification::SPECIFICATION_VERSION_HISTORY and turned into rdoc * Removed blanket rescue in default_executable. Hope it doesn't blow up! :P * Removed nearly all metaprogramming from Specification. Yay for attr_accessor! * SourceIndex#initialize changed to prefer an array of spec dirs, defaulting to none. * SourceIndex.new is now the preferred way to create SourceIndex instances. *gasp* * Specification#validate now checks that array attribs are indeed arrays. * Specification.default_value is now an instance method. * Switched Specification::TODAY to be proper midnight @ UTC * Update Gem::RemoteFetcher\'s User-Agent to handle RUBY_ENGINE and RUBY_REVISION when patchlevel is -1 * UpdateCommand#gems_to_update now returns (name, version) pairs. * UpdateCommand#which_to_update now takes an optional system argument. * 11 bug fixes: * Added missing remote fetcher require to pristine command (aarnell) * Building gems now checks to ensure all required fields are non-nil * Fix option parser when summary is nil. * Fixed `gem contents` to work with the lightweight specifications * Fixed `gem update --system x.y.z` where x.y.z == latest version. (MGPalmer) * Fixed gem contents sorting and tests. (MGPalmer) * Fixed intermittant problem in `gem fetch` with --platform specified (quix) * Fixed lightweight specifications so `gem rdoc` will generate proper documentation * MockGemUI#terminate_interaction should not raise Gem::SystemExitException. (MGPalmer) * RubyGems now raises a better error for broken .gem files. Bug #29067 by Elias Baixas * `gem update` now uniq's command line arguments. From luislavena at gmail.com Fri Apr 1 21:43:24 2011 From: luislavena at gmail.com (Luis Lavena) Date: Fri, 1 Apr 2011 22:43:24 -0300 Subject: [Rubygems-developers] [Ruby] [ANN] rubygems 1.7.1 In-Reply-To: <3209DC3F-64D7-4899-AC65-D9886D9F4583@segment7.net> References: <3209DC3F-64D7-4899-AC65-D9886D9F4583@segment7.net> Message-ID: On Fri, Apr 1, 2011 at 7:57 PM, Eric Hodel wrote: > After much finger-pointing, rubygems-update version 1.7.1 has been released! > For what is worth: ruby 1.8.7 (2011-02-18 patchlevel 334) [i386-mingw32] 835 tests, 2730 assertions, 0 failures, 0 errors, 18 skips ruby 1.9.2p180 (2011-02-18) [i386-mingw32] 822 tests, 2704 assertions, 0 failures, 0 errors, 20 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 halostatue at gmail.com Sat Apr 2 00:25:25 2011 From: halostatue at gmail.com (Austin Ziegler) Date: Sat, 2 Apr 2011 00:25:25 -0400 Subject: [Rubygems-developers] Problem with some gems @cert_chains and 1.7.1 Message-ID: Trying to install savon, I get: Fetching: builder-3.0.0.gem (100%) Fetching: crack-0.1.8.gem (100%) Fetching: rack-1.2.2.gem (100%) Fetching: ntlm-http-0.1.1.gem (100%) ERROR: While executing gem ... (Gem::FormatException) ntlm-http-0.1.1 has an invalid value for @cert_chain Looks like this affects a few popular packages, too: http://stackoverflow.com/questions/5520333/rails-3-install-error-invalid-value-for-cert-chain Apparently rolling back to 1.6.2 works, but that's a bit ugly, obviously. -a -- Austin Ziegler ? halostatue at gmail.com ? austin at halostatue.ca http://www.halostatue.ca/ ? http://twitter.com/halostatue From noreply at rubyforge.org Sun Apr 3 08:42:57 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 3 Apr 2011 08:42:57 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29074 ] Can't upgrade to newer rubygems version with explicit version number Message-ID: <20110403124257.B8FC7185836C@rubyforge.org> Bugs item #29074, was opened at 2011-03-10 17:44 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29074&group_id=126 Category: None Group: None Status: Open Resolution: Accepted Priority: 3 Submitted By: Martin Tepper (mgpalmer) Assigned to: Ryan Davis (zenspider) Summary: Can't upgrade to newer rubygems version with explicit version number Initial Comment: Hi everybody ! I've already briefly explained the problem here: http://help.rubygems.org/discussions/problems/514-cant-upgrade-to-newer-rubygems-version-with-explicit-version-number Basically, upgrading rubygems to a specific, higher-than-now version (or the latest version) doesn't work as it is. You can workaround by installing rubygems-update manually, but I think it's quite unobvious why you can't just tell the target version and be done with it. I've poked around in the code and found a solution. Here's my take on it: https://github.com/MGPalmer/rubygems/commit/a1bd03cd597a3a0fc1d13059c582ac7266c34fb8 I haven't really contributed to a project before like this, is there anything else I need to do ? Run tests etc. ? Thanks for all your work on the ruby ecosystem ! Best regards, Martin Tepper ---------------------------------------------------------------------- >Comment By: Martin Tepper (mgpalmer) Date: 2011-04-03 14:42 Message: Thanks for including the fix. For googlers: http://blog.segment7.net/2011/04/01/rubygems-1- 7-0 ---------------------------------------------------------------------- Comment By: Martin Tepper (mgpalmer) Date: 2011-03-15 13:41 Message: I've cleaned up the spec: https://github.com/MGPalmer/rubygems/commit/2ebbfc71ea5548df8 d3bab6bffe3524324bff211 Please also see my comment on your comment - IMHO, making it easier for developers is more important in this case. But changing the test style is not my mission here :) ---------------------------------------------------------------------- Comment By: Martin Tepper (mgpalmer) Date: 2011-03-11 17:27 Message: Alrighty: The test: https://github.com/MGPalmer/rubygems/commit/a3c6ac8663032fcb c84d4a1193ec246fd4143fb3 The fix: https://github.com/MGPalmer/rubygems/commit/a57fde4082e76e69 2e292c9312e935f3282f61de And to get all tests working for me locally, I had to fix this: https://github.com/MGPalmer/rubygems/commit/f97755c77ece0929 0e7536e367fa07ce69b363cd It doesn't seem to be connected with the other changes, as I got this error when running the tests against the vanilla 1.6.2 rubygems, but I didn't want to leave the error in. Feel free to ignore this. ---------------------------------------------------------------------- Comment By: Martin Tepper (mgpalmer) Date: 2011-03-11 08:34 Message: Ah yes. Sorry, it actually only fails when trying to install explicitly the latest online version: $ sudo gem update --system 1.6.1 --no-rdoc --no-ri Updating rubygems-update Successfully installed rubygems-update-1.6.1 Installing RubyGems 1.6.1 RubyGems 1.6.1 installed ... $ sudo gem update --system 1.6.2 --no-rdoc --no-ri Latest version currently installed. Aborting. I'll make a test for that. ---------------------------------------------------------------------- Comment By: Eric Hodel (drbrain) Date: 2011-03-10 23:17 Message: I can't reproduce: $ sudo gem update --system 1.6.0 --no-rdoc --no-ri Updating rubygems-update Successfully installed rubygems-update-1.6.0 Installing RubyGems 1.6.0 RubyGems 1.6.0 installed ? $ sudo gem update --system 1.6.1 --no-rdoc --no-ri Updating rubygems-update Successfully installed rubygems-update-1.6.1 Installing RubyGems 1.6.1 RubyGems 1.6.1 installed ? $ sudo gem update --system 1.6.0 --no-rdoc --no-ri Updating rubygems-update Successfully installed rubygems-update-1.6.0 Installing RubyGems 1.6.0 RubyGems 1.6.0 installed ? $ sudo gem update --system --no-rdoc --no-ri Updating rubygems-update Fetching: rubygems-update-1.6.2.gem (100%) Successfully installed rubygems-update-1.6.2 Installing RubyGems 1.6.2 RubyGems 1.6.2 installed Your commit does not have any test changes. I would like to see a failing test first as the update functionality does have tests. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29074&group_id=126 From noreply at rubyforge.org Mon Apr 4 20:41:01 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 4 Apr 2011 20:41:01 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29074 ] Can't upgrade to newer rubygems version with explicit version number Message-ID: <20110405004101.EA6E4185834E@rubyforge.org> Bugs item #29074, was opened at 2011-03-10 08:44 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29074&group_id=126 Category: None Group: None >Status: Closed Resolution: Accepted Priority: 3 Submitted By: Martin Tepper (mgpalmer) Assigned to: Ryan Davis (zenspider) Summary: Can't upgrade to newer rubygems version with explicit version number Initial Comment: Hi everybody ! I've already briefly explained the problem here: http://help.rubygems.org/discussions/problems/514-cant-upgrade-to-newer-rubygems-version-with-explicit-version-number Basically, upgrading rubygems to a specific, higher-than-now version (or the latest version) doesn't work as it is. You can workaround by installing rubygems-update manually, but I think it's quite unobvious why you can't just tell the target version and be done with it. I've poked around in the code and found a solution. Here's my take on it: https://github.com/MGPalmer/rubygems/commit/a1bd03cd597a3a0fc1d13059c582ac7266c34fb8 I haven't really contributed to a project before like this, is there anything else I need to do ? Run tests etc. ? Thanks for all your work on the ruby ecosystem ! Best regards, Martin Tepper ---------------------------------------------------------------------- Comment By: Martin Tepper (mgpalmer) Date: 2011-04-03 05:42 Message: Thanks for including the fix. For googlers: http://blog.segment7.net/2011/04/01/rubygems-1- 7-0 ---------------------------------------------------------------------- Comment By: Martin Tepper (mgpalmer) Date: 2011-03-15 05:41 Message: I've cleaned up the spec: https://github.com/MGPalmer/rubygems/commit/2ebbfc71ea5548df8 d3bab6bffe3524324bff211 Please also see my comment on your comment - IMHO, making it easier for developers is more important in this case. But changing the test style is not my mission here :) ---------------------------------------------------------------------- Comment By: Martin Tepper (mgpalmer) Date: 2011-03-11 08:27 Message: Alrighty: The test: https://github.com/MGPalmer/rubygems/commit/a3c6ac8663032fcb c84d4a1193ec246fd4143fb3 The fix: https://github.com/MGPalmer/rubygems/commit/a57fde4082e76e69 2e292c9312e935f3282f61de And to get all tests working for me locally, I had to fix this: https://github.com/MGPalmer/rubygems/commit/f97755c77ece0929 0e7536e367fa07ce69b363cd It doesn't seem to be connected with the other changes, as I got this error when running the tests against the vanilla 1.6.2 rubygems, but I didn't want to leave the error in. Feel free to ignore this. ---------------------------------------------------------------------- Comment By: Martin Tepper (mgpalmer) Date: 2011-03-10 23:34 Message: Ah yes. Sorry, it actually only fails when trying to install explicitly the latest online version: $ sudo gem update --system 1.6.1 --no-rdoc --no-ri Updating rubygems-update Successfully installed rubygems-update-1.6.1 Installing RubyGems 1.6.1 RubyGems 1.6.1 installed ... $ sudo gem update --system 1.6.2 --no-rdoc --no-ri Latest version currently installed. Aborting. I'll make a test for that. ---------------------------------------------------------------------- Comment By: Eric Hodel (drbrain) Date: 2011-03-10 14:17 Message: I can't reproduce: $ sudo gem update --system 1.6.0 --no-rdoc --no-ri Updating rubygems-update Successfully installed rubygems-update-1.6.0 Installing RubyGems 1.6.0 RubyGems 1.6.0 installed ? $ sudo gem update --system 1.6.1 --no-rdoc --no-ri Updating rubygems-update Successfully installed rubygems-update-1.6.1 Installing RubyGems 1.6.1 RubyGems 1.6.1 installed ? $ sudo gem update --system 1.6.0 --no-rdoc --no-ri Updating rubygems-update Successfully installed rubygems-update-1.6.0 Installing RubyGems 1.6.0 RubyGems 1.6.0 installed ? $ sudo gem update --system --no-rdoc --no-ri Updating rubygems-update Fetching: rubygems-update-1.6.2.gem (100%) Successfully installed rubygems-update-1.6.2 Installing RubyGems 1.6.2 RubyGems 1.6.2 installed Your commit does not have any test changes. I would like to see a failing test first as the update functionality does have tests. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29074&group_id=126 From ryand-ruby at zenspider.com Mon Apr 4 21:30:17 2011 From: ryand-ruby at zenspider.com (Ryan Davis) Date: Mon, 4 Apr 2011 18:30:17 -0700 Subject: [Rubygems-developers] Problem with some gems @cert_chains and 1.7.1 In-Reply-To: References: Message-ID: <85712898-6E6F-4B03-A492-D90F17FACDD1@zenspider.com> On Apr 1, 2011, at 21:25 , Austin Ziegler wrote: > Trying to install savon, I get: > > Fetching: builder-3.0.0.gem (100%) > Fetching: crack-0.1.8.gem (100%) > Fetching: rack-1.2.2.gem (100%) > Fetching: ntlm-http-0.1.1.gem (100%) > ERROR: While executing gem ... (Gem::FormatException) > ntlm-http-0.1.1 has an invalid value for @cert_chain > > Looks like this affects a few popular packages, too: > > http://stackoverflow.com/questions/5520333/rails-3-install-error-invalid-value-for-cert-chain > > Apparently rolling back to 1.6.2 works, but that's a bit ugly, obviously. OK. I have a repro. The real problem is that the spec for ntlm-http is invalid and has a nil value where there should be an empty array. I'll poke at a fix, but really ntlm-http should fix their spec. OK. I just committed a fix so it'll do the following: > WARNING: ntlm-http-0.1.1 has an invalid nil value for @cert_chain > Successfully installed ntlm-http-0.1.1 Eric will cherry pick that into the 1.7 branch and release. Eric, please review 8fd9038 and attack. From lsegal at soen.ca Mon Apr 4 15:17:11 2011 From: lsegal at soen.ca (Loren Segal) Date: Mon, 04 Apr 2011 15:17:11 -0400 Subject: [Rubygems-developers] has_rdoc deprecation and alternatives? Message-ID: <4D9A1937.8000906@soen.ca> Hi, First a little background. I am the maintainer of YARD, and we've recently been getting reports that the RubyGems plugin that has been shipped with YARD since 2009 is not compatible with RubyGems 1.7.x. I have a fix in place, but given RubyGems' future, I am unsure how long the fix will continue to work. I'm posting here in hopes of finding a way to improve YARD's RubyGems' plugin in a sustainable / maintainable way. I've just taken a look at the new RubyGems release, and it seems like has_rdoc is finally going away. While I understand that it's not in the best interest of the community to allow gem specifications to disable documentation generation, the field has performed another task of differentiating gems with RDoc/YARD documentation for at least the last 2 years; at least with the addition of the YARD plugin. Removing the field (as 1.7.x has) disables the plugin from letting gems specify which documentation tool their gem is compatible with. If my history serves me right, the has_rdoc field was introduced for this very reason (although at the time documentation tools in question were different). The YARD plugin packaged has made use of this "unused" field to do just that. I think it's important to accept that there are many other documentation tools in Ruby's ecosystem than RDoc; and it's not even just YARD. Rocco is another great new documentation tool that deserves integration into the ecosystem as well. Although I'm aware the RubyGems maintainers also work on RDoc, I don't see any reason for RubyGems to be hardcoded with support for only one documentation tool. Ultimately, it should be the gem author's decision which documentation tool is used to generate their documentation. As a gem author myself, I do not want any of my documentation generated with RDoc, because they are not compatible with the tool, and this affects how effective the locally generated docs are for my users. This is certainly an issue for other libraries as well, some of which are fairly popular: like Haml, Sass, DataMapper, mongo-ruby-driver, Spidr, etc. (a short list can be found here: https://github.com/lsegal/yard/wiki/Who's-Using-YARD%3F ) Clearly it would be worthless to just come in here and complain that things are broken. Again, although I've fixed the problem in YARD, it requires even more hacking in RubyGems internals, something I hate doing just as much as you likely hate me doing it. Therefore, I want to figure out a way for all of us to move forward productively. In that vein, here are a couple of suggested alternatives to has_rdoc that also solve some other issues raised by the community: 1. Add a `doc_files` field instead. Just like `files` and `test_files`, it may be useful for gem maintainers to package their own *statically generated* documentation files to the gem package. This most directly solves the tool problem, because the tool is now no longer part of the installation process. This suggestion has other really great benefits too, such as drastically improving install time (as you know, rdoc gen is the slowest part of a gem install). You've likely seen the complaints on twitter, and DHH's recent mis-tweet about suggesting --no-rdoc --no-ri to workaround this issue. Packaging static docs rather than having the client generate the docs on *every install* will be much more efficient for everybody. A few notes about this one: firstly, RG can package basic gem commands to build the docs quickly with rdoc for the gem author to use; I don't mind having such basic helper methods in the tool. Secondly, if doc_files is not present, I wouldn't mind a built-in fallback on RDoc here either. The specification of the files would allow gem authors to override the default behaviour, which I think is reasonable. Finally, the ri parsing can continue to work regardless of the setting. Parsing the docs for ri is fairly quick, and not really a compatibility or speed issue. 2. If extra bloat to gem package size is an issue with #1, perhaps we can give gem authors the ability to package these documentation files separately from the gem itself and push the documentation package independently of the gem (gem push_docs ...). This way, a gem install could perform an extra fetch of the doc archive file from a separate repo if present, or skip this extra download if --no-rdoc is provided. This certainly adds a bit of extra weight to RG's infrastructure, but I think it would be manageable and quite a helpful addition. Again, "generate once distribute everywhere" is much more efficient than having each user re-generate the exact same docs. I think it's clear that many users are frustrated with having to do the re-generation all the time if they want the static docs locally. 3. Add a `doc_bin` if none of the above are feasible. This would allow gem authors to specify the [Ruby] command to execute when installing a gem. If security is an issue, it could be executed with ruby -S so as to ensure it's coming from an already installed gem. At least then, users could specify s.doc_bin = 'yard', or s.doc_bin = 'rocco'. If this is added, having a `doc_bin_options` would be helpful too (just like the gemspec currently has rdoc_extra_options). There might be some compatibility issues with this one, specifically how to know what the output path is, but nothing insurmountable here. Again, I really hope we can figure out a way to have all of the documentation tools co-existing with RubyGems. Given that RubyGems is a core part of the way Ruby users interact in the ecosystem, I think it's important for users to have extra choices about things like documentation et al. - Loren From noreply at rubyforge.org Tue Apr 5 02:22:56 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 5 Apr 2011 02:22:56 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29114 ] older gems interfere with loading paths from external gems Message-ID: <20110405062256.3718318583A4@rubyforge.org> Bugs item #29114, was opened at 2011-04-05 00:22 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29114&group_id=126 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Daniel DeLeo (danielsdeleo) Assigned to: Nobody (None) Summary: older gems interfere with loading paths from external gems Initial Comment: I'm seeing this issue with the Chef project. In the current release version, we have a bunch of files under chef/knife/whatever.rb In the current prerelease version, we have plugin support using Gem.find_files (thanks for the patch guys!), so we've moved much of this code out to separate gems. We strip the paths we get back from Gem.find_files to the normal relative paths (e.g., chef/knife/ec2_server_create) so that we can uniq them and rely on rubygems to load the latest version of the gem. The problem I'm seeing is this: Chef 0.9.14 has a file 'chef/knife/ec2_instance_data' Chef 0.10.0 does not have this file. the knife-ec2 plugin *does* have a file 'chef/knife/ec2_instance_data' When I have both Chef 0.9.14 and Chef 0.10 installed and Chef 0.10 attempts to `require 'chef/knife/ec2_instance_data'` it gets a LoadError /Users/ddeleo/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:57:in `require': no such file to load -- chef/knife/ec2_instance_data (LoadError) from /Users/ddeleo/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:57:in `rescue in require' from /Users/ddeleo/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:35:in `require' from /Users/ddeleo/.rvm/gems/ruby-1.9.2-p180/gems/chef-0.10.0.beta.6/lib/chef/knife/core/subcommand_loader.rb:39:in `block in load_commands' # etc. If I run `gem which chef/knife/ec2_instance_data`, I see that rubygems prefers the one in the old version of chef: gem which chef/knife/ec2_instance_data /Users/ddeleo/.rvm/gems/ruby-1.9.2-p180/gems/chef-0.9.14/lib/chef/knife/ec2_instance_data.rb When I uninstall the old version of chef, so that I have only the 0.10 beta, then chef 0.10 can successfully require the 'chef/knife/ec2_instance_data' file, and `gem which` reports that the file is located in the knife-ec2 gem. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29114&group_id=126 From noreply at rubyforge.org Tue Apr 5 02:27:59 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 5 Apr 2011 02:27:59 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29114 ] older gems interfere with loading paths from external gems Message-ID: <20110405062800.47FF818583A4@rubyforge.org> Bugs item #29114, was opened at 2011-04-05 00:22 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29114&group_id=126 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Daniel DeLeo (danielsdeleo) Assigned to: Nobody (None) Summary: older gems interfere with loading paths from external gems Initial Comment: I'm seeing this issue with the Chef project. In the current release version, we have a bunch of files under chef/knife/whatever.rb In the current prerelease version, we have plugin support using Gem.find_files (thanks for the patch guys!), so we've moved much of this code out to separate gems. We strip the paths we get back from Gem.find_files to the normal relative paths (e.g., chef/knife/ec2_server_create) so that we can uniq them and rely on rubygems to load the latest version of the gem. The problem I'm seeing is this: Chef 0.9.14 has a file 'chef/knife/ec2_instance_data' Chef 0.10.0 does not have this file. the knife-ec2 plugin *does* have a file 'chef/knife/ec2_instance_data' When I have both Chef 0.9.14 and Chef 0.10 installed and Chef 0.10 attempts to `require 'chef/knife/ec2_instance_data'` it gets a LoadError /Users/ddeleo/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:57:in `require': no such file to load -- chef/knife/ec2_instance_data (LoadError) from /Users/ddeleo/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:57:in `rescue in require' from /Users/ddeleo/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:35:in `require' from /Users/ddeleo/.rvm/gems/ruby-1.9.2-p180/gems/chef-0.10.0.beta.6/lib/chef/knife/core/subcommand_loader.rb:39:in `block in load_commands' # etc. If I run `gem which chef/knife/ec2_instance_data`, I see that rubygems prefers the one in the old version of chef: gem which chef/knife/ec2_instance_data /Users/ddeleo/.rvm/gems/ruby-1.9.2-p180/gems/chef-0.9.14/lib/chef/knife/ec2_instance_data.rb When I uninstall the old version of chef, so that I have only the 0.10 beta, then chef 0.10 can successfully require the 'chef/knife/ec2_instance_data' file, and `gem which` reports that the file is located in the knife-ec2 gem. ---------------------------------------------------------------------- >Comment By: Daniel DeLeo (danielsdeleo) Date: 2011-04-05 00:27 Message: Forcing activation of the plugin gem (e.g., knife-ec2 in the example) works around the error, though extracting the gem name is messy to say the least. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29114&group_id=126 From noreply at rubyforge.org Tue Apr 5 11:16:53 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 5 Apr 2011 11:16:53 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Feature Requests-29115 ] Plugin-ize Sourcing/Fetching Message-ID: <20110405151653.C1BA718583A7@rubyforge.org> Feature Requests item #29115, was opened at 2011-04-05 08:16 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=578&aid=29115&group_id=126 Category: other Group: None Status: Open Resolution: None Priority: 3 Submitted By: Brasten Sager (brasten) Assigned to: Nobody (None) Summary: Plugin-ize Sourcing/Fetching Initial Comment: I would love the ability to extend Rubygems' remote fetcher to handle custom or currently unsupported protocols. In my case, I'd like to be able to build a private, secured internal gems repo and being able to add plugins to the RemoteFetcher would be great for this. As an example, a workable solution might be to check for a Fetcher class derived from the scheme -- e.g., "mygems://blah.net" might look for a Gems::MygemsRemoteFetcher or something along those lines. Personally, I would like to install Rubygems via SSH similar to how our private git repos function -- doing this as a Rubygems plugin seems ideal. I'm willing to hack on this idea myself so long as the general concept is acceptable to the maintainers. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=578&aid=29115&group_id=126 From noreply at rubyforge.org Tue Apr 5 14:01:31 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 5 Apr 2011 14:01:31 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29116 ] Mega slowness in custom require Message-ID: <20110405180131.32E30185838E@rubyforge.org> Bugs item #29116, was opened at 2011-04-05 18:01 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29116&group_id=126 Category: #gem and #require methods Group: None Status: Open Resolution: None Priority: 3 Submitted By: Sam Goldstein (samgoldstein) Assigned to: Nobody (None) 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! ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29116&group_id=126 From noreply at rubyforge.org Tue Apr 5 14:02:58 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 5 Apr 2011 14:02:58 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29116 ] Mega slowness in custom require Message-ID: <20110405180258.AB85E185838E@rubyforge.org> Bugs item #29116, was opened at 2011-04-05 18:01 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29116&group_id=126 Category: #gem and #require methods Group: None Status: Open Resolution: None Priority: 3 Submitted By: Sam Goldstein (samgoldstein) Assigned to: Nobody (None) Summary: Mega slowness in custom require Initial Comment: I recently upgraded to rubygems 1.6.5 and started experiencing a major slowdown loading the environment for a Rails 2.3 application. I traced the problem back to the Kernel.require (custom_require.rb) and Gem.loaded_path?. It seems that searching $LOADED_FEATURES repeatedly is inefficient and results in a 4x slowdown in my specific case. I've downgraded to rubygems 1.3.5 which doesn't suffer from this problem. This is a major hurdle to developing in ruby, as it takes me ~45 seconds to load the environment and run one test. Below is some console output demonstrating the problem. /www/aboutus/app_root [master] $ time rake environment (in /www/aboutus/app_root) real 0m11.407s user 0m8.787s sys 0m2.552s /www/aboutus/app_root [master] $ sudo gem update --system Updating RubyGems Updating rubygems-update Successfully installed rubygems-update-1.7.1 Updating RubyGems to 1.7.1 Installing RubyGems 1.7.1 RubyGems 1.7.1 installed === 1.7.1 / 2011-03-32 * 1 bug fix: * Fixed missing file in Manifest.txt. (Also a bug in hoe was fixed where `rake check_manifest` showing a diff would not exit with an error.) ------------------------------------------------------------------------------ RubyGems installed the following executables: /usr/local/bin/gem /www/aboutus/app_root [master] $ time rake environment (in /www/aboutus/app_root) NOTE: SourceIndex.new(hash) is deprecated; From /www/aboutus/app_root/config/../vendor/rails/railties/lib/rails/vendor_gem_source_index.rb:100:in `new'. real 0m46.707s user 0m41.200s sys 0m5.394s Thanks! ---------------------------------------------------------------------- >Comment By: Sam Goldstein (samgoldstein) Date: 2011-04-05 18:02 Message: BTW the first environment load was with gem version 1.3.5 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29116&group_id=126 From noreply at rubyforge.org Tue Apr 5 14:07:44 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 5 Apr 2011 14:07:44 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29116 ] Mega slowness in custom require Message-ID: <20110405180745.EFF5C1858367@rubyforge.org> Bugs item #29116, was opened at 2011-04-05 18:01 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29116&group_id=126 Category: #gem and #require methods Group: None Status: Open Resolution: None Priority: 3 Submitted By: Sam Goldstein (samgoldstein) Assigned to: Nobody (None) Summary: Mega slowness in custom require Initial Comment: I recently upgraded to rubygems 1.6.5 and started experiencing a major slowdown loading the environment for a Rails 2.3 application. I traced the problem back to the Kernel.require (custom_require.rb) and Gem.loaded_path?. It seems that searching $LOADED_FEATURES repeatedly is inefficient and results in a 4x slowdown in my specific case. I've downgraded to rubygems 1.3.5 which doesn't suffer from this problem. This is a major hurdle to developing in ruby, as it takes me ~45 seconds to load the environment and run one test. Below is some console output demonstrating the problem. /www/aboutus/app_root [master] $ time rake environment (in /www/aboutus/app_root) real 0m11.407s user 0m8.787s sys 0m2.552s /www/aboutus/app_root [master] $ sudo gem update --system Updating RubyGems Updating rubygems-update Successfully installed rubygems-update-1.7.1 Updating RubyGems to 1.7.1 Installing RubyGems 1.7.1 RubyGems 1.7.1 installed === 1.7.1 / 2011-03-32 * 1 bug fix: * Fixed missing file in Manifest.txt. (Also a bug in hoe was fixed where `rake check_manifest` showing a diff would not exit with an error.) ------------------------------------------------------------------------------ RubyGems installed the following executables: /usr/local/bin/gem /www/aboutus/app_root [master] $ time rake environment (in /www/aboutus/app_root) NOTE: SourceIndex.new(hash) is deprecated; From /www/aboutus/app_root/config/../vendor/rails/railties/lib/rails/vendor_gem_source_index.rb:100:in `new'. real 0m46.707s user 0m41.200s sys 0m5.394s Thanks! ---------------------------------------------------------------------- >Comment By: Sam Goldstein (samgoldstein) Date: 2011-04-05 18:07 Message: More info on gem dependencies and installed gems. $ rake gems (in /www/aboutus/compostus/compost) - [F] thrift_client ~> 0.4.3 - [I] thrift - [I] thrift = 0.2.0.4 - [F] simple_uuid = 0.1.1 - [F] cassandra = 0.8.2 - [F] thrift_client >= 0.4.0 - [I] thrift - [I] json - [R] rake - [F] simple_uuid >= 0.1.0 - [F] rack ~> 1.0.0 - [F] diff-lcs = 1.1.2 - [I] ffi ~> 0.6.0 - [R] rake >= 0.8.7 - [F] haml - [I] libxml-ruby - [I] hpricot >= 0.8.1 - [I] json - [I] mysql = 2.8.1 - [F] net-ssh - [F] ya2yaml = 0.26 - [F] ruby-openid = 2.1.6 - [F] mechanize = 1.0.0 - [I] nokogiri >= 1.2.1 - [I] nokogiri - [F] composite_primary_keys = 2.2.2 - [R] activerecord >= 2.2.0 - [F] aws-s3 = 0.6.2 - [F] xml-simple - [F] builder - [F] mime-types - [F] right_aws - [F] right_http_connection >= 1.2.4 - [F] fastercsv = 1.5.0 - [I] levenshtein - [F] newrelic_rpm = 2.13.4 - [F] after_commit ~> 1.0.7 - [R] activerecord - [F] less = 1.2.21 - [F] treetop >= 1.4.2 - [F] polyglot >= 0.3.1 - [F] mutter >= 0.4.2 - [F] treetop = 1.4.8 - [F] polyglot >= 0.3.1 - [F] mime-types = 1.16 - [I] curb = 0.7.8 I = Installed F = Frozen R = Framework (loaded before rails starts) $ gem list abstract (1.0.0) actionmailer (3.0.5, 3.0.3, 2.3.4, 2.2.2) actionpack (3.0.5, 3.0.3, 2.3.4, 2.2.2) activemodel (3.0.5, 3.0.3) activerecord (3.0.5, 3.0.3, 2.3.4, 2.2.2) activeresource (3.0.5, 3.0.3, 2.3.4, 2.2.2) activesupport (3.0.5, 3.0.3, 2.3.11, 2.3.8, 2.3.7, 2.3.5, 2.3.4, 2.2.2) acts_as_commentable (3.0.1, 2.0.2) addressable (2.2.4) after_commit (1.0.7, 1.0.5) amatch (0.2.3) amazon_sdb (0.6.7) amqp (0.6.0) ar-extensions (0.8.0) arel (2.0.9, 2.0.8) au_document_parser (0.5.3, 0.4.3, 0.4.2, 0.4.1, 0.4.0, 0.3.2, 0.3.1, 0.3.0, 0.2.4) autotest-growl (0.1.7) aws-s3 (0.6.2) babel (0.1.4) builder (2.1.2) bundler (1.0.10) capistrano (2.5.5) capybara (0.3.0) carmen (0.2.5) cassandra (0.7.2, 0.6) cgi_multipart_eof_fix (2.5.0) cheat (1.2.1) chronic (0.3.0, 0.2.3) clearance (0.10.3.2, 0.8.8, 0.8.3) compass (0.8.17) compass-960-plugin (0.9.11) composite_primary_keys (2.2.2) configuration (1.1.0) crack (0.1.4) cucumber (0.10.2, 0.6.3, 0.6.2) cucumber-rails (0.3.2, 0.2.4, 0.2.3) culerity (0.2.6) curb (0.7.8, 0.7.7.1, 0.7.1) daemons (1.0.10) database_cleaner (0.4.3) diesel (0.1.4) diff-lcs (1.1.2) differ (0.1.1) diffy (2.0.1) dirb (1.0.0, 0.1.1, 0.1.0) duration (0.1.0) erubis (2.6.6) eventmachine (0.12.10) factory_girl (1.2.3) fakefs (0.2.1) faker (0.3.1) faraday (0.5.7) fastercsv (1.5.0) fastthread (1.0.7) ffi (0.6.3, 0.5.4, 0.5.3) file-tail (1.0.4) fixjour (0.1.6) flexmock (0.8.6) gem_plugin (0.2.3) gemcutter (0.5.0) geminstaller (0.5.4) geokit (1.5.0) getopt-declare (1.28) gherkin (2.3.5) git (1.2.5) gltail (0.1.8) gravatar (1.0) grit (2.0.0, 1.1.1) haml (3.0.25, 3.0.13, 2.2.19, 2.2.9) heroku (1.9.8) highline (1.5.1) hoe (2.3.3) hpricot (0.8.1) httparty (0.5.0) i18n (0.5.0) icalendar (1.1.2, 1.1.0) jeweler (1.4.0) jm81-whois (0.5.0) json (1.4.6, 1.2.0, 1.1.6) json_pure (1.2.0) launchy (0.3.3) less (1.2.21) levenshtein (0.2.0) libxml-ruby (1.1.3) log4r (1.1.9) lorem (0.1.2) macaddr (1.0.0) mail (2.2.15, 1.5.2) maruku (0.6.0) mechanize (1.0.0, 0.9.3) memcache-client (1.7.4) micronaut (0.3.0) mime-types (1.16) mkrf (0.2.3) mocha (0.9.8) mongrel (1.1.5) more (0.1.1) multi_json (0.0.5) multipart-post (1.1.0) mutter (0.5.3) mysql (2.8.1) needle (1.3.0) net-scp (1.0.2) net-sftp (2.0.4, 1.1.0) net-ssh (2.0.15, 1.1.4, 1.0.10) net-ssh-gateway (1.0.1) newrelic_rpm (2.14.0, 2.9.9, 2.9.8, 2.9.3) nkallen-cache-money (0.2.5) nokogiri (1.4.0) open4 (1.0.1) paperclip (2.3.1.1) parseexcel (0.5.2) polyglot (0.3.1, 0.3.0, 0.2.9) rack (1.2.2, 1.2.1, 1.0.1) rack-mount (0.6.14, 0.6.13) rack-rewrite (1.0.2) rack-test (0.5.7, 0.5.3) rails (3.0.5, 3.0.3, 2.3.4, 2.2.2) railties (3.0.5, 3.0.3) rake (0.8.7, 0.8.3) rcov (0.9.6) RedCloth (4.2.2) redis (2.1.1) redis-namespace (0.10.0) resque (1.13.0) rest-client (1.4.2) riddle (1.0.11, 1.0.8) right_aws (1.10.0) right_http_connection (1.2.4) rpx_now (0.6.11) rspec (2.5.0, 1.3.0, 1.2.9, 1.2.7) rspec-core (2.5.1) rspec-expectations (2.5.0) rspec-mocks (2.5.0) rspec-rails (2.5.0, 1.3.2, 1.2.9, 1.2.7) ruby-aws (1.2.0) ruby-graphviz (0.9.21) ruby-ole (1.2.10.1) ruby-opengl (0.60.1) ruby-openid (2.1.6) ruby-prof (0.9.2, 0.8.1) rubyforge (2.0.4, 2.0.3) rubygems-update (1.7.1, 1.6.2) RubyInline (3.8.1) rufus-tokyo (0.1.14) rvm (0.0.98) selenium-webdriver (0.0.14) sequel (3.14.0, 3.9.0, 3.6.0) simple_uuid (0.0.2) sinatra (1.2.1, 1.1.2, 1.0, 0.9.5) slave (1.2.1) smurf (1.0.3) snailgun (1.0.6) spork (0.7.5) spreadsheet (0.6.4.1) sqlite3 (1.3.3) sqlite3-ruby (1.3.3, 1.2.5) stemmer (1.0.1) syntax (1.0.0) technicalpickles-jeweler (1.2.1) term-ansicolor (1.0.5, 1.0.4) Text (1.1.2) thinking-sphinx (1.3.18, 1.3.14) thor (0.14.6) thoughtbot-factory_girl (1.2.2) thrift (0.2.0.4) thrift_client (0.3.3, 0.3.1) tilt (1.2.2) timetrap (1.7.4, 1.4.0, 1.3.0, 1.2.1, 1.2.0, 1.1.3, 1.1.2) treetop (1.4.9, 1.4.8, 1.4.2) tzinfo (0.3.26, 0.3.25, 0.3.24) uuid (2.1.0, 2.0.1) uuidtools (2.1.2, 2.1.1) vegas (0.1.8) vlad (1.3.2) webrat (0.7.0, 0.6.0, 0.4.4) will_paginate (2.3.11) xhtmldiff (1.0.0) xml-simple (1.0.14, 1.0.12) xmpp4r (0.4) ya2yaml (0.26) ZenTest (4.1.4) ---------------------------------------------------------------------- Comment By: Sam Goldstein (samgoldstein) Date: 2011-04-05 18:02 Message: BTW the first environment load was with gem version 1.3.5 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29116&group_id=126 From drbrain at segment7.net Tue Apr 5 17:33:08 2011 From: drbrain at segment7.net (Eric Hodel) Date: Tue, 5 Apr 2011 14:33:08 -0700 Subject: [Rubygems-developers] [ANN] RubyGems 1.7.2 Message-ID: rubygems-update version 1.7.2 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.7.2 / 2011-04-05 * 1 Bug Fix: * Warn on loading bad spec array values (ntlm-http gem has nil in its cert chain) From drbrain at segment7.net Tue Apr 5 18:17:52 2011 From: drbrain at segment7.net (Eric Hodel) Date: Tue, 5 Apr 2011 15:17:52 -0700 Subject: [Rubygems-developers] has_rdoc deprecation and alternatives? In-Reply-To: <4D9A1937.8000906@soen.ca> References: <4D9A1937.8000906@soen.ca> Message-ID: <3144FD33-9304-44CD-8CCF-B0247001AAE1@segment7.net> On Apr 4, 2011, at 12:17 PM, Loren Segal wrote: > ? the [has_rdoc] field has performed another task of differentiating gems with RDoc/YARD documentation for at least the last 2 years; at least with the addition of the YARD plugin. How does YARD fail when there's no special flag? > Removing the field (as 1.7.x has) disables the plugin from letting gems specify which documentation tool their gem is compatible with. If my history serves me right, the has_rdoc field was introduced for this very reason (although at the time documentation tools in question were different). The YARD plugin packaged has made use of this "unused" field to do just that. I think this was more to allow gem authors to say "I'm lazy and can't be bothered to write documentation". > I think it's important to accept that there are many other documentation tools in Ruby's ecosystem than RDoc; and it's not even just YARD. Rocco is another great new documentation tool that deserves integration into the ecosystem as well. Although I'm aware the RubyGems maintainers also work on RDoc, I don't see any reason for RubyGems to be hardcoded with support for only one documentation tool. Agreed, Gem::DocManager is not very useful to RDoc, either. > Clearly it would be worthless to just come in here and complain that things are broken. Again, although I've fixed the problem in YARD, it requires even more hacking in RubyGems internals, something I hate doing just as much as you likely hate me doing it. Therefore, I want to figure out a way for all of us to move forward productively. In that vein, here are a couple of suggested alternatives to has_rdoc that also solve some other issues raised by the community: Yes, one thing you can guarantee about monkey patches is that they'll probably break. > 1. Add a `doc_files` field instead. Just like `files` and `test_files`, it may be useful for gem maintainers to package their own *statically generated* documentation files to the gem package. While this won't be true for every package, for rubygems-update the generated rdoc HTML by itself (481K as a tar.gz) is twice the size of the current gem (252K). This would triple costs for downloading and storing gems without ri data. > 2. If extra bloat to gem package size is an issue with #1, perhaps we can give gem authors the ability to package these documentation files separately from the gem itself and push the documentation package independently of the gem (gem push_docs ?). I'm not fond of this as newer versions of rdoc (or yard) may fix bugs or add useful features that will Just Work on existing sources. It's also an extra step that authors (that don't use Hoe) would have to implement. > 3. Add a `doc_bin` if none of the above are feasible. This would allow gem authors to specify the [Ruby] command to execute when installing a gem. I have an alternate solution: Add aadditional hook to the rubygems install sequence, pre_installs and post_installs (plural). For example: $ gem install rails -i ~/tmp/gems [pre-installs with 24 gems] [pre-install for activesupport] Successfully installed activesupport-3.0.5 [post-install for activesupport] [pre-install for builder] Successfully installed builder-2.1.2 [post-install for builder] [?] [pre-install for rails] Successfully installed rails-3.0.5 [post-install for rails] 24 gems installed [post-installs with 24 gems] Additionally --no-rdoc and --no-ri will be replaced with a --[no-]document option which will take a list of documentation types to generate: gem install rails --no-document # generate no documentation gem install rails --document # generate rdoc and ri documentation gem install rails --document=ri,rdoc # same gem install rails --document=ri # generate only ri documentation gem install rails --document=yard # generate yard documentation There will also be a hook to change the default documentation set from %w[ri rdoc], probably on Gem.configuration From lsegal at soen.ca Tue Apr 5 19:53:52 2011 From: lsegal at soen.ca (Loren Segal) Date: Tue, 05 Apr 2011 19:53:52 -0400 Subject: [Rubygems-developers] has_rdoc deprecation and alternatives? In-Reply-To: <3144FD33-9304-44CD-8CCF-B0247001AAE1@segment7.net> References: <4D9A1937.8000906@soen.ca> <3144FD33-9304-44CD-8CCF-B0247001AAE1@segment7.net> Message-ID: <4D9BAB90.7050204@soen.ca> Hey Eric, On 4/5/2011 6:17 PM, Eric Hodel wrote: > On Apr 4, 2011, at 12:17 PM, Loren Segal wrote: > >> ? the [has_rdoc] field has performed another task of differentiating gems with RDoc/YARD documentation for at least the last 2 years; at least with the addition of the YARD plugin. > How does YARD fail when there's no special flag? We're basically monkeypatching the install_ri/install_rdoc functionality right now. If has_rdoc isn't set, YARD just silently lets RDoc do its thing without issue. The failure we had was because the Gem::Specification class was refactored to remove the overwrite_accessor feature, which we relied on. The new plugin code will throw out a standard attribute if that method is not present-- and, again, if that attribute stops getting checked, it should just fail gracefully. >> 2. If extra bloat to gem package size is an issue with #1, perhaps we can give gem authors the ability to package these documentation files separately from the gem itself and push the documentation package independently of the gem (gem push_docs ?). > I'm not fond of this as newer versions of rdoc (or yard) may fix bugs or add useful features that will Just Work on existing sources. Well, by the same token, many versions of RDoc and YARD have bugs that cause problems for gems. For instance, we just (finally!) pulled in a change that fixes a really old bug in the RDoc shipped with 1.8.6 that causes parsing of YARD's code to fail: http://bit.ly/hyD9qu -- users with 1.8.6 (and there are a bunch) still report this error every now and then. Having static docs, we wouldn't have to deal with modifying anything in YARD's codebase and putting out another release just to fix the docs, we'd just need to push static docs. Keep in mind this would also allow maintainers to package docs that are generated neither by rdoc or any other ruby doc tool-- ie. statically hand crafted docs. Although that might sound crazy, there are a handful of authors that might be interested in this capability. In fact, having run rubydoc.info for the last little while, we've actually gotten a few people asking if they could host static files on the site (unfortunately we can't) for this exact purpose. Some gem authors actually want to have extreme control over what their html docs look like, and perform post-processing on the html generated by tools like rdoc and yard, then host the docs on their own sites for this reason. Here are two more attempts at convincing you, and then I'll move on: The speed issue: again, generating the docs is slow. YARD is even slower than RDoc (although not by that much), so the tool is not the solution. Munging a bunch of HTML files is just a slow process. Users often want documentation locally, but don't necessarily want to wait 30-60 seconds to get it. I've actually gotten requests from users on where they can download the static rails docs that we host on rubydoc.info, so we made the package available. Why generate it yourself when you can download 400kb or even just a few MB of data? That's 60 seconds vs. 0.5-2 seconds; epic win. No tool can beat that. I'm pretty sure users would be drooling over something like this, and improve the amount of users actually bothering to install docs. Even *I* use --no-rdoc --no-ri because of speed issues. OTOH I wouldn't turn it off if it was just a static download away. Yes, yes, it's certainly anecdotal, but I'd wager that other users feel the same way. If so, more users getting the docs == a good thing. Secondly, there are plugins and dependencies to deal with. YARD supports a variety of plugins, and increasingly, gem authors are making use of these. A gem author might use plugin X, but it isn't present on every user's system. Instead of adding a [potentially large] dependency on a gem *just to generate the docs*, it would be way better to just let the author have the dependencies on their system and not have the users worry about this. Consider this: Haml generates its YARD docs with `-m markdown --markup-provider maruku`, meaning it uses Markdown formatting through the Maruku library. This means to generate YARD docs on a `gem install haml`, it needs to first install maruku, which in turn depends on `syntax`. That's 2 extra gems just to generate the docs on the client side. All of this could be avoided by allowing the Haml guys to release a statically generated doc package. I'll bet RDoc might have similar issues with third party plugins. > It's also an extra step that authors (that don't use Hoe) would have to implement. I'm not sure this extra step would be a big deal to most gem authors. It would be interesting to take a poll on this and see; I'd bet you'd get enormous support in favour of pre-built docs. Again, if the docs package isn't present, RubyGems can do the standard local generation it always has, with whatever tool is present, etc.. It would only be if this package was found that it would be fetched. This gives gem maintainers the *choice* to release static docs if they care and want their users to have fast installs. I've never used hoe, nor do I use any variant of release-tool to package my gems, and I've had no issue. `gem build` and `gem push` is sufficient for me. If there was a `gem build_docs ` and `gem push `, that would be super easy to use. I don't see this as being a big barrier to entry; certainly not that complicated that you'd need to bring in a tool like hoe. I wonder if Nick knows anything about how complicated this would be to add from the Gemcutter side of things. >> 3. Add a `doc_bin` if none of the above are feasible. This would allow gem authors to specify the [Ruby] command to execute when installing a gem. > I have an alternate solution: > > Add aadditional hook to the rubygems install sequence, pre_installs and post_installs (plural). For example: > *snip* > There will also be a hook to change the default documentation set from %w[ri rdoc], probably on Gem.configuration I like this idea. You've just reminded me that I've wished the RubyGems plugin API had this functionality many many times. However, there are a few downsides with doing things this way: 1. It's still kind of important to allow gem authors to pick which tool their docs can be generated with. Again, some authors care a lot about what their docs look like, and this is problematic when a tool is not compatible with their documentation format. YARD formatting, for instance, doesn't look very good at all when generated by RDoc (or rocco, or tomdoc), and as a gem author I'd want the ability to opt out of the client using other tools, if yard was available. I'm guessing the authors who use YARD formatting in their docs would agree with this as well. I certainly understand that allowing the client to choose is important (give them overrides), but the authors should have a say, too. Don't you agree? 2. If a user was gem installing gemX that depended on yard, or some lib that used YARD formatting, their command `gem install --document=rdoc` would apply to both libs (right?). In other words, if gemX used RDoc formatting and the dependency did not, they'd be stuck generating the wrong type of docs for at least one of the libs. So again, there *is* some validity to making this a per-gem setting. 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. - Loren From lsegal at soen.ca Tue Apr 5 20:01:36 2011 From: lsegal at soen.ca (Loren Segal) Date: Tue, 05 Apr 2011 20:01:36 -0400 Subject: [Rubygems-developers] has_rdoc deprecation and alternatives? In-Reply-To: <4D9BAB90.7050204@soen.ca> References: <4D9A1937.8000906@soen.ca> <3144FD33-9304-44CD-8CCF-B0247001AAE1@segment7.net> <4D9BAB90.7050204@soen.ca> Message-ID: <4D9BAD60.7030801@soen.ca> Oops, forgot an important point, On 4/5/2011 7:53 PM, Loren Segal wrote: >>> 2. If extra bloat to gem package size is an issue with #1, perhaps >>> we can give gem authors the ability to package these documentation >>> files separately from the gem itself and push the documentation >>> package independently of the gem (gem push_docs ?). >> I'm not fond of this as newer versions of rdoc (or yard) may fix bugs >> or add useful features that will Just Work on existing sources. I should add: having a push_docs feature would (could?) allow maintainers to re-push docs for an existing version-- in other words they could retroactively push docs for version X.Y.Z. So if new versions of RDoc (or YARD) start to look better and/or fix bugs, they could re-generate and re-push the docs for that version. Optionally, they could remove the docs if they're stale, letting the client side generation kick in-- and of course, users could be allowed to override doc fetching and let the client side do its thing instead (--no-fetch-doc or something?) - Loren From lsegal at soen.ca Tue Apr 5 20:31:02 2011 From: lsegal at soen.ca (Loren Segal) Date: Tue, 05 Apr 2011 20:31:02 -0400 Subject: [Rubygems-developers] has_rdoc deprecation and alternatives? In-Reply-To: <3144FD33-9304-44CD-8CCF-B0247001AAE1@segment7.net> References: <4D9A1937.8000906@soen.ca> <3144FD33-9304-44CD-8CCF-B0247001AAE1@segment7.net> Message-ID: <4D9BB446.7010105@soen.ca> Hey Eric, On 4/5/2011 6:17 PM, Eric Hodel wrote: > On Apr 4, 2011, at 12:17 PM, Loren Segal wrote: > >> ? the [has_rdoc] field has performed another task of differentiating >> gems with RDoc/YARD documentation for at least the last 2 years; at >> least with the addition of the YARD plugin. > How does YARD fail when there's no special flag? We're basically monkeypatching the install_ri/install_rdoc functionality right now. If has_rdoc isn't set, YARD just silently lets RDoc do its thing without issue. The failure we had was because the Gem::Specification class was refactored to remove the overwrite_accessor feature, which we relied on. The new plugin code will throw out a standard attribute if that method is not present-- and, again, if that attribute stops getting checked, it should just fail gracefully. >> 2. If extra bloat to gem package size is an issue with #1, perhaps we >> can give gem authors the ability to package these documentation files >> separately from the gem itself and push the documentation package >> independently of the gem (gem push_docs ?). > I'm not fond of this as newer versions of rdoc (or yard) may fix bugs > or add useful features that will Just Work on existing sources. Well, by the same token, many versions of RDoc and YARD have bugs that cause problems for gems. For instance, we just (finally!) pulled in a change that fixes a really old bug in the RDoc shipped with 1.8.6 that causes parsing of YARD's code to fail: http://bit.ly/hyD9qu -- users with 1.8.6 (and there are a bunch) still report this error every now and then. Having static docs, we wouldn't have to deal with modifying anything in YARD's codebase and putting out another release just to fix the docs, we'd just need to push static docs. Keep in mind this would also allow maintainers to package docs that are generated neither by rdoc or any other ruby doc tool-- ie. statically hand crafted docs. Although that might sound crazy, there are a handful of authors that might be interested in this capability. In fact, having run rubydoc.info for the last little while, we've actually gotten a few people asking if they could host static files on the site (unfortunately we can't) for this exact purpose. Some gem authors actually want to have extreme control over what their html docs look like, and perform post-processing on the html generated by tools like rdoc and yard, then host the docs on their own sites for this reason. Here are two more attempts at convincing you, and then I'll move on: The speed issue: again, generating the docs is slow. YARD is even slower than RDoc (although not by that much), so the tool is not the solution. Munging a bunch of HTML files is just a slow process. Users often want documentation locally, but don't necessarily want to wait 30-60 seconds to get it. I've actually gotten requests from users on where they can download the static rails docs that we host on rubydoc.info, so we made the package available. Why generate it yourself when you can download 400kb or even just a few MB of data? That's 60 seconds vs. 0.5-2 seconds; epic win. No tool can beat that. I'm pretty sure users would be drooling over something like this, and improve the amount of users actually bothering to install docs. Even *I* use --no-rdoc --no-ri because of speed issues. OTOH I wouldn't turn it off if it was just a static download away. Yes, yes, it's certainly anecdotal, but I'd wager that other users feel the same way. If so, more users getting the docs == a good thing. Secondly, there are plugins and dependencies to deal with. YARD supports a variety of plugins, and increasingly, gem authors are making use of these. A gem author might use plugin X, but it isn't present on every user's system. Instead of adding a [potentially large] dependency on a gem *just to generate the docs*, it would be way better to just let the author have the dependencies on their system and not have the users worry about this. Consider this: Haml generates its YARD docs with `-m markdown --markup-provider maruku`, meaning it uses Markdown formatting through the Maruku library. This means to generate YARD docs on a `gem install haml`, it needs to first install maruku, which in turn depends on `syntax`. That's 2 extra gems just to generate the docs on the client side. All of this could be avoided by allowing the Haml guys to release a statically generated doc package. I'll bet RDoc might have similar issues with third party plugins. > It's also an extra step that authors (that don't use Hoe) would have > to implement. I'm not sure this extra step would be a big deal to most gem authors. It would be interesting to take a poll on this and see; I'd bet you'd get enormous support in favour of pre-built docs. Again, if the docs package isn't present, RubyGems can do the standard local generation it always has, with whatever tool is present, etc.. It would only be if this package was found that it would be fetched. This gives gem maintainers the *choice* to release static docs if they care and want their users to have fast installs. I've never used hoe, nor do I use any variant of release-tool to package my gems, and I've had no issue. `gem build` and `gem push` is sufficient for me. If there was a `gem build_docs ` and `gem push `, that would be super easy to use. I don't see this as being a big barrier to entry; certainly not that complicated that you'd need to bring in a tool like hoe. I wonder if Nick knows anything about how complicated this would be to add from the Gemcutter side of things. >> 3. Add a `doc_bin` if none of the above are feasible. This would >> allow gem authors to specify the [Ruby] command to execute when >> installing a gem. > I have an alternate solution: > > Add aadditional hook to the rubygems install sequence, pre_installs > and post_installs (plural). For example: > *snip* > There will also be a hook to change the default documentation set from > %w[ri rdoc], probably on Gem.configuration I like this idea. You've just reminded me that I've wished the RubyGems plugin API had this functionality many many times. However, there are a few downsides with doing things this way: 1. It's still kind of important to allow gem authors to pick which tool their docs can be generated with. Again, some authors care a lot about what their docs look like, and this is problematic when a tool is not compatible with their documentation format. YARD formatting, for instance, doesn't look very good at all when generated by RDoc (or rocco, or tomdoc), and as a gem author I'd want the ability to opt out of the client using other tools, if yard was available. I'm guessing the authors who use YARD formatting in their docs would agree with this as well. I certainly understand that allowing the client to choose is important (give them overrides), but the authors should have a say, too. Don't you agree? 2. If a user was gem installing gemX that depended on yard, or some lib that used YARD formatting, their command `gem install --document=rdoc` would apply to both libs (right?). In other words, if gemX used RDoc formatting and the dependency did not, they'd be stuck generating the wrong type of docs for at least one of the libs. So again, there *is* some validity to making this a per-gem setting. 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. - Loren From djberg96 at gmail.com Tue Apr 5 21:13:41 2011 From: djberg96 at gmail.com (Daniel Berger) Date: Tue, 5 Apr 2011 19:13:41 -0600 Subject: [Rubygems-developers] Latest rubygems test results on Windows Message-ID: Ruby 1.8.7 p330 Windows Vista Latest from a git pull. Haven't looked into these yet, but thought I should mention them. 2) Error: test_execute_gem_path(TestGemCommandsUnpackCommand): NoMethodError: private method `gsub' called for # ./lib/rubygems/path_support.rb:65:in `path=' ./lib/rubygems/path_support.rb:64:in `map!' ./lib/rubygems/path_support.rb:64:in `path=' ./lib/rubygems/path_support.rb:32:in `initialize' ./lib/rubygems.rb:396:in `new' ./lib/rubygems.rb:396:in `paths=' ./test/rubygems/test_gem_commands_unpack_command.rb:78:in `test_execute_gem_path' C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:817:in `__send__' C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:817:in `run' C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:664:in `_run_suite' C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:657:in `map' C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:657:in `_run_suite' C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:647:in `_run_suites' C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:647:in `map' C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:647:in `_run_suites' C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:623:in `_run_anything' C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:778:in `run_tests' C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:765:in `send' C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:765:in `run' C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:764:in `each' C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:764:in `run' C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:558:in `autorun' -e:1 3) Error: test_execute_gem_path_missing(TestGemCommandsUnpackCommand): NoMethodError: private method `gsub' called for # ./lib/rubygems/path_support.rb:65:in `path=' ./lib/rubygems/path_support.rb:64:in `map!' ./lib/rubygems/path_support.rb:64:in `path=' ./lib/rubygems/path_support.rb:32:in `initialize' ./lib/rubygems.rb:396:in `new' ./lib/rubygems.rb:396:in `paths=' ./test/rubygems/test_gem_commands_unpack_command.rb:99:in `test_execute_gem_path_missing' C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:817:in `__send__' C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:817:in `run' C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:664:in `_run_suite' C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:657:in `map' C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:657:in `_run_suite' C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:647:in `_run_suites' C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:647:in `map' C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:647:in `_run_suites' C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:623:in `_run_anything' C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:778:in `run_tests' C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:765:in `send' C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:765:in `run' C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:764:in `each' C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:764:in `run' C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:558:in `autorun' -e:1 5) Error: test_fs_ensure_gem_subdirectories(TestGemFS): Errno::EACCES: Permission denied - C:/Users/djberge/AppData/Local/Temp/test_rubygems_956 C:/Ruby187/lib/ruby/1.8/fileutils.rb:1293:in `rmdir' C:/Ruby187/lib/ruby/1.8/fileutils.rb:1293:in `remove_dir1' C:/Ruby187/lib/ruby/1.8/fileutils.rb:1307:in `platform_support' C:/Ruby187/lib/ruby/1.8/fileutils.rb:1292:in `remove_dir1' C:/Ruby187/lib/ruby/1.8/fileutils.rb:1285:in `remove' C:/Ruby187/lib/ruby/1.8/fileutils.rb:757:in `remove_entry' C:/Ruby187/lib/ruby/1.8/fileutils.rb:1341:in `postorder_traverse' C:/Ruby187/lib/ruby/1.8/fileutils.rb:755:in `remove_entry' C:/Ruby187/lib/ruby/1.8/fileutils.rb:613:in `rm_r' C:/Ruby187/lib/ruby/1.8/fileutils.rb:609:in `each' C:/Ruby187/lib/ruby/1.8/fileutils.rb:609:in `rm_r' ./test/rubygems/test_gem_fs.rb:38:in `test_fs_ensure_gem_subdirectories' C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:817:in `__send__' C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:817:in `run' C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:664:in `_run_suite' C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:657:in `map' C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:657:in `_run_suite' C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:647:in `_run_suites' C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:647:in `map' C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:647:in `_run_suites' C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:623:in `_run_anything' C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:778:in `run_tests' C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:765:in `send' C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:765:in `run' C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:764:in `each' C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:764:in `run' C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:558:in `autorun' -e:1 14) Failure: test_readable?(TestGemPath) [./test/rubygems/test_gem_path.rb:39]: File no longer thinks C:/Users/djberge/AppData/Local/Temp/test_rubygems_956 is readable 15) Failure: test_writable?(TestGemPath) [./test/rubygems/test_gem_path.rb:53]: File no longer thinks C:/Users/djberge/AppData/Local/Temp/test_rubygems_956 is writable Plus a bunch of warnings at the end: 861 tests, 2830 assertions, 2 failures, 3 errors, 18 skips ./lib/rubygems/test_case.rb:32: warning: redefine searcher= ./lib/rubygems/test_case.rb:40: warning: redefine source_index= ./lib/rubygems/test_case.rb:48: warning: redefine win_platform= ./lib/rubygems/test_case.rb:56: warning: redefine ruby= ./lib/rubygems/test_case.rb:97: warning: method redefined; discarding old setup ./lib/rubygems/test_case.rb:197: warning: method redefined; discarding old teardown ./lib/rubygems/test_case.rb:229: warning: method redefined; discarding old install_gem ./lib/rubygems/test_case.rb:245: warning: method redefined; discarding old uninstall_gem ./lib/rubygems/test_case.rb:256: warning: method redefined; discarding old create_tmpdir ./lib/rubygems/test_case.rb:267: warning: method redefined; discarding old mu_pp ./lib/rubygems/test_case.rb:277: warning: method redefined; discarding old read_cache ./lib/rubygems/test_case.rb:286: warning: method redefined; discarding old read_binary ./lib/rubygems/test_case.rb:293: warning: method redefined; discarding old write_file ./lib/rubygems/test_case.rb:316: warning: method redefined; discarding old quick_gem ./lib/rubygems/test_case.rb:344: warning: method redefined; discarding old quick_spec ./lib/rubygems/test_case.rb:372: warning: method redefined; discarding old util_build_gem ./lib/rubygems/test_case.rb:395: warning: method redefined; discarding old util_clear_gems ./lib/rubygems/test_case.rb:404: warning: method redefined; discarding old install_specs ./lib/rubygems/test_case.rb:416: warning: method redefined; discarding old new_spec ./lib/rubygems/test_case.rb:436: warning: method redefined; discarding old util_spec ./lib/rubygems/test_case.rb:456: warning: method redefined; discarding old util_gem ./lib/rubygems/test_case.rb:485: warning: method redefined; discarding old util_gzip ./lib/rubygems/test_case.rb:513: warning: method redefined; discarding old util_make_gems ./lib/rubygems/test_case.rb:573: warning: method redefined; discarding old util_set_arch ./lib/rubygems/test_case.rb:589: warning: method redefined; discarding old util_setup_fake_fetche ./lib/rubygems/test_case.rb:619: warning: method redefined; discarding old util_setup_spec_fetche ./lib/rubygems/test_case.rb:656: warning: method redefined; discarding old util_zip ./lib/rubygems/test_case.rb:663: warning: redefine win_platform? ./lib/rubygems/test_case.rb:670: warning: method redefined; discarding old win_platform? ./lib/rubygems/test_case.rb:678: warning: redefine vc_windows? ./lib/rubygems/test_case.rb:686: warning: method redefined; discarding old vc_windows? ./lib/rubygems/test_case.rb:695: warning: redefine make_command ./lib/rubygems/test_case.rb:704: warning: method redefined; discarding old make_command ./lib/rubygems/test_case.rb:711: warning: method redefined; discarding old nmake_found? ./lib/rubygems/test_case.rb:720: warning: redefine process_based_port ./lib/rubygems/test_case.rb:727: warning: method redefined; discarding old process_based_port ./lib/rubygems/test_case.rb:734: warning: method redefined; discarding old build_rake_in ./lib/rubygems/test_case.rb:752: warning: redefine rubybin ./lib/rubygems/test_case.rb:792: warning: method redefined; discarding old dep ./lib/rubygems/test_case.rb:799: warning: method redefined; discarding old req ./lib/rubygems/test_case.rb:807: warning: method redefined; discarding old spec ./lib/rubygems/test_case.rb:814: warning: method redefined; discarding old v ./lib/rubygems/test_utilities.rb:29: warning: method redefined; discarding old initialize ./lib/rubygems/test_utilities.rb:34: warning: method redefined; discarding old find_data ./lib/rubygems/test_utilities.rb:46: warning: method redefined; discarding old fetch_path ./lib/rubygems/test_utilities.rb:61: warning: method redefined; discarding old open_uri_or_path ./lib/rubygems/test_utilities.rb:71: warning: method redefined; discarding old request ./lib/rubygems/test_utilities.rb:84: warning: method redefined; discarding old fetch_size ./lib/rubygems/test_utilities.rb:99: warning: method redefined; discarding old download ./lib/rubygems/test_utilities.rb:116: warning: method redefined; discarding old download_to_cache ./lib/rubygems/test_utilities.rb:131: warning: redefine fetcher= ./lib/rubygems/test_utilities.rb:145: warning: method redefined; discarding old initialize ./lib/rubygems/test_utilities.rb:152: warning: method redefined; discarding old string Regards, Dan From erik at hollensbe.org Tue Apr 5 22:15:34 2011 From: erik at hollensbe.org (Erik Hollensbe) Date: Tue, 5 Apr 2011 22:15:34 -0400 Subject: [Rubygems-developers] Latest rubygems test results on Windows In-Reply-To: References: Message-ID: I'll be looking into these tomorrow or thursday. -Erik On Apr 5, 2011, at 9:13 PM, Daniel Berger wrote: > Ruby 1.8.7 p330 > Windows Vista > Latest from a git pull. > > Haven't looked into these yet, but thought I should mention them. > > 2) Error: > test_execute_gem_path(TestGemCommandsUnpackCommand): > NoMethodError: private method `gsub' called for # > ./lib/rubygems/path_support.rb:65:in `path=' > ./lib/rubygems/path_support.rb:64:in `map!' > ./lib/rubygems/path_support.rb:64:in `path=' > ./lib/rubygems/path_support.rb:32:in `initialize' > ./lib/rubygems.rb:396:in `new' > ./lib/rubygems.rb:396:in `paths=' > ./test/rubygems/test_gem_commands_unpack_command.rb:78:in > `test_execute_gem_path' > C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:817:in > `__send__' > C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:817:in > `run' > C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:664:in > `_run_suite' > C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:657:in > `map' > C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:657:in > `_run_suite' > C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:647:in > `_run_suites' > C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:647:in > `map' > C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:647:in > `_run_suites' > C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:623:in > `_run_anything' > C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:778:in > `run_tests' > C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:765:in > `send' > C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:765:in > `run' > C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:764:in > `each' > C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:764:in > `run' > C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:558:in > `autorun' > -e:1 > > 3) Error: > test_execute_gem_path_missing(TestGemCommandsUnpackCommand): > NoMethodError: private method `gsub' called for # > ./lib/rubygems/path_support.rb:65:in `path=' > ./lib/rubygems/path_support.rb:64:in `map!' > ./lib/rubygems/path_support.rb:64:in `path=' > ./lib/rubygems/path_support.rb:32:in `initialize' > ./lib/rubygems.rb:396:in `new' > ./lib/rubygems.rb:396:in `paths=' > ./test/rubygems/test_gem_commands_unpack_command.rb:99:in > `test_execute_gem_path_missing' > C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:817:in > `__send__' > C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:817:in > `run' > C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:664:in > `_run_suite' > C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:657:in > `map' > C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:657:in > `_run_suite' > C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:647:in > `_run_suites' > C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:647:in > `map' > C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:647:in > `_run_suites' > C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:623:in > `_run_anything' > C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:778:in > `run_tests' > C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:765:in > `send' > C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:765:in > `run' > C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:764:in > `each' > C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:764:in > `run' > C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:558:in > `autorun' > -e:1 > > 5) Error: > test_fs_ensure_gem_subdirectories(TestGemFS): > Errno::EACCES: Permission denied - > C:/Users/djberge/AppData/Local/Temp/test_rubygems_956 > C:/Ruby187/lib/ruby/1.8/fileutils.rb:1293:in `rmdir' > C:/Ruby187/lib/ruby/1.8/fileutils.rb:1293:in `remove_dir1' > C:/Ruby187/lib/ruby/1.8/fileutils.rb:1307:in `platform_support' > C:/Ruby187/lib/ruby/1.8/fileutils.rb:1292:in `remove_dir1' > C:/Ruby187/lib/ruby/1.8/fileutils.rb:1285:in `remove' > C:/Ruby187/lib/ruby/1.8/fileutils.rb:757:in `remove_entry' > C:/Ruby187/lib/ruby/1.8/fileutils.rb:1341:in `postorder_traverse' > C:/Ruby187/lib/ruby/1.8/fileutils.rb:755:in `remove_entry' > C:/Ruby187/lib/ruby/1.8/fileutils.rb:613:in `rm_r' > C:/Ruby187/lib/ruby/1.8/fileutils.rb:609:in `each' > C:/Ruby187/lib/ruby/1.8/fileutils.rb:609:in `rm_r' > ./test/rubygems/test_gem_fs.rb:38:in `test_fs_ensure_gem_subdirectories' > C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:817:in > `__send__' > C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:817:in > `run' > C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:664:in > `_run_suite' > C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:657:in > `map' > C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:657:in > `_run_suite' > C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:647:in > `_run_suites' > C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:647:in > `map' > C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:647:in > `_run_suites' > C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:623:in > `_run_anything' > C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:778:in > `run_tests' > C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:765:in > `send' > C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:765:in > `run' > C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:764:in > `each' > C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:764:in > `run' > C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:558:in > `autorun' > -e:1 > > 14) Failure: > test_readable?(TestGemPath) [./test/rubygems/test_gem_path.rb:39]: > File no longer thinks > C:/Users/djberge/AppData/Local/Temp/test_rubygems_956 is readable > > 15) Failure: > test_writable?(TestGemPath) [./test/rubygems/test_gem_path.rb:53]: > File no longer thinks > C:/Users/djberge/AppData/Local/Temp/test_rubygems_956 is writable > > Plus a bunch of warnings at the end: > > 861 tests, 2830 assertions, 2 failures, 3 errors, 18 skips > ./lib/rubygems/test_case.rb:32: warning: redefine searcher= > ./lib/rubygems/test_case.rb:40: warning: redefine source_index= > ./lib/rubygems/test_case.rb:48: warning: redefine win_platform= > ./lib/rubygems/test_case.rb:56: warning: redefine ruby= > ./lib/rubygems/test_case.rb:97: warning: method redefined; discarding old setup > ./lib/rubygems/test_case.rb:197: warning: method redefined; discarding > old teardown > ./lib/rubygems/test_case.rb:229: warning: method redefined; discarding > old install_gem > ./lib/rubygems/test_case.rb:245: warning: method redefined; discarding > old uninstall_gem > ./lib/rubygems/test_case.rb:256: warning: method redefined; discarding > old create_tmpdir > ./lib/rubygems/test_case.rb:267: warning: method redefined; discarding old mu_pp > ./lib/rubygems/test_case.rb:277: warning: method redefined; discarding > old read_cache > ./lib/rubygems/test_case.rb:286: warning: method redefined; discarding > old read_binary > ./lib/rubygems/test_case.rb:293: warning: method redefined; discarding > old write_file > ./lib/rubygems/test_case.rb:316: warning: method redefined; discarding > old quick_gem > ./lib/rubygems/test_case.rb:344: warning: method redefined; discarding > old quick_spec > ./lib/rubygems/test_case.rb:372: warning: method redefined; discarding > old util_build_gem > ./lib/rubygems/test_case.rb:395: warning: method redefined; discarding > old util_clear_gems > ./lib/rubygems/test_case.rb:404: warning: method redefined; discarding > old install_specs > ./lib/rubygems/test_case.rb:416: warning: method redefined; discarding > old new_spec > ./lib/rubygems/test_case.rb:436: warning: method redefined; discarding > old util_spec > ./lib/rubygems/test_case.rb:456: warning: method redefined; discarding > old util_gem > ./lib/rubygems/test_case.rb:485: warning: method redefined; discarding > old util_gzip > ./lib/rubygems/test_case.rb:513: warning: method redefined; discarding > old util_make_gems > ./lib/rubygems/test_case.rb:573: warning: method redefined; discarding > old util_set_arch > ./lib/rubygems/test_case.rb:589: warning: method redefined; discarding > old util_setup_fake_fetche > ./lib/rubygems/test_case.rb:619: warning: method redefined; discarding > old util_setup_spec_fetche > ./lib/rubygems/test_case.rb:656: warning: method redefined; discarding > old util_zip > ./lib/rubygems/test_case.rb:663: warning: redefine win_platform? > ./lib/rubygems/test_case.rb:670: warning: method redefined; discarding > old win_platform? > ./lib/rubygems/test_case.rb:678: warning: redefine vc_windows? > ./lib/rubygems/test_case.rb:686: warning: method redefined; discarding > old vc_windows? > ./lib/rubygems/test_case.rb:695: warning: redefine make_command > ./lib/rubygems/test_case.rb:704: warning: method redefined; discarding > old make_command > ./lib/rubygems/test_case.rb:711: warning: method redefined; discarding > old nmake_found? > ./lib/rubygems/test_case.rb:720: warning: redefine process_based_port > ./lib/rubygems/test_case.rb:727: warning: method redefined; discarding > old process_based_port > ./lib/rubygems/test_case.rb:734: warning: method redefined; discarding > old build_rake_in > ./lib/rubygems/test_case.rb:752: warning: redefine rubybin > ./lib/rubygems/test_case.rb:792: warning: method redefined; discarding old dep > ./lib/rubygems/test_case.rb:799: warning: method redefined; discarding old req > ./lib/rubygems/test_case.rb:807: warning: method redefined; discarding old spec > ./lib/rubygems/test_case.rb:814: warning: method redefined; discarding old v > ./lib/rubygems/test_utilities.rb:29: warning: method redefined; > discarding old initialize > ./lib/rubygems/test_utilities.rb:34: warning: method redefined; > discarding old find_data > ./lib/rubygems/test_utilities.rb:46: warning: method redefined; > discarding old fetch_path > ./lib/rubygems/test_utilities.rb:61: warning: method redefined; > discarding old open_uri_or_path > ./lib/rubygems/test_utilities.rb:71: warning: method redefined; > discarding old request > ./lib/rubygems/test_utilities.rb:84: warning: method redefined; > discarding old fetch_size > ./lib/rubygems/test_utilities.rb:99: warning: method redefined; > discarding old download > ./lib/rubygems/test_utilities.rb:116: warning: method redefined; > discarding old download_to_cache > ./lib/rubygems/test_utilities.rb:131: warning: redefine fetcher= > ./lib/rubygems/test_utilities.rb:145: warning: method redefined; > discarding old initialize > ./lib/rubygems/test_utilities.rb:152: warning: method redefined; > discarding old string > > Regards, > > Dan > _______________________________________________ > Rubygems-developers mailing list > http://rubyforge.org/projects/rubygems > Rubygems-developers at rubyforge.org > http://rubyforge.org/mailman/listinfo/rubygems-developers From erik at hollensbe.org Wed Apr 6 03:36:51 2011 From: erik at hollensbe.org (Erik Hollensbe) Date: Wed, 6 Apr 2011 03:36:51 -0400 Subject: [Rubygems-developers] Latest rubygems test results on Windows In-Reply-To: References: Message-ID: <18568D59-7754-4162-AA7B-3D7468EEBC45@hollensbe.org> Dan, can you pull my latest head and try? I think I've resolved these issues. git clone git://github.com/erikh/rubygems Thanks! -Erik On Apr 5, 2011, at 9:13 PM, Daniel Berger wrote: > Ruby 1.8.7 p330 > Windows Vista > Latest from a git pull. > > Haven't looked into these yet, but thought I should mention them. > > 2) Error: > test_execute_gem_path(TestGemCommandsUnpackCommand): > NoMethodError: private method `gsub' called for # > ./lib/rubygems/path_support.rb:65:in `path=' > ./lib/rubygems/path_support.rb:64:in `map!' > ./lib/rubygems/path_support.rb:64:in `path=' > ./lib/rubygems/path_support.rb:32:in `initialize' > ./lib/rubygems.rb:396:in `new' > ./lib/rubygems.rb:396:in `paths=' > ./test/rubygems/test_gem_commands_unpack_command.rb:78:in > `test_execute_gem_path' > C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:817:in > `__send__' > C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:817:in > `run' > C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:664:in > `_run_suite' > C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:657:in > `map' > C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:657:in > `_run_suite' > C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:647:in > `_run_suites' > C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:647:in > `map' > C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:647:in > `_run_suites' > C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:623:in > `_run_anything' > C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:778:in > `run_tests' > C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:765:in > `send' > C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:765:in > `run' > C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:764:in > `each' > C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:764:in > `run' > C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:558:in > `autorun' > -e:1 > > 3) Error: > test_execute_gem_path_missing(TestGemCommandsUnpackCommand): > NoMethodError: private method `gsub' called for # > ./lib/rubygems/path_support.rb:65:in `path=' > ./lib/rubygems/path_support.rb:64:in `map!' > ./lib/rubygems/path_support.rb:64:in `path=' > ./lib/rubygems/path_support.rb:32:in `initialize' > ./lib/rubygems.rb:396:in `new' > ./lib/rubygems.rb:396:in `paths=' > ./test/rubygems/test_gem_commands_unpack_command.rb:99:in > `test_execute_gem_path_missing' > C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:817:in > `__send__' > C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:817:in > `run' > C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:664:in > `_run_suite' > C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:657:in > `map' > C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:657:in > `_run_suite' > C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:647:in > `_run_suites' > C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:647:in > `map' > C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:647:in > `_run_suites' > C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:623:in > `_run_anything' > C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:778:in > `run_tests' > C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:765:in > `send' > C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:765:in > `run' > C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:764:in > `each' > C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:764:in > `run' > C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:558:in > `autorun' > -e:1 > > 5) Error: > test_fs_ensure_gem_subdirectories(TestGemFS): > Errno::EACCES: Permission denied - > C:/Users/djberge/AppData/Local/Temp/test_rubygems_956 > C:/Ruby187/lib/ruby/1.8/fileutils.rb:1293:in `rmdir' > C:/Ruby187/lib/ruby/1.8/fileutils.rb:1293:in `remove_dir1' > C:/Ruby187/lib/ruby/1.8/fileutils.rb:1307:in `platform_support' > C:/Ruby187/lib/ruby/1.8/fileutils.rb:1292:in `remove_dir1' > C:/Ruby187/lib/ruby/1.8/fileutils.rb:1285:in `remove' > C:/Ruby187/lib/ruby/1.8/fileutils.rb:757:in `remove_entry' > C:/Ruby187/lib/ruby/1.8/fileutils.rb:1341:in `postorder_traverse' > C:/Ruby187/lib/ruby/1.8/fileutils.rb:755:in `remove_entry' > C:/Ruby187/lib/ruby/1.8/fileutils.rb:613:in `rm_r' > C:/Ruby187/lib/ruby/1.8/fileutils.rb:609:in `each' > C:/Ruby187/lib/ruby/1.8/fileutils.rb:609:in `rm_r' > ./test/rubygems/test_gem_fs.rb:38:in `test_fs_ensure_gem_subdirectories' > C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:817:in > `__send__' > C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:817:in > `run' > C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:664:in > `_run_suite' > C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:657:in > `map' > C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:657:in > `_run_suite' > C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:647:in > `_run_suites' > C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:647:in > `map' > C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:647:in > `_run_suites' > C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:623:in > `_run_anything' > C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:778:in > `run_tests' > C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:765:in > `send' > C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:765:in > `run' > C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:764:in > `each' > C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:764:in > `run' > C:/Ruby187/lib/ruby/gems/1.8/gems/minitest-2.0.2/lib/minitest/unit.rb:558:in > `autorun' > -e:1 > > 14) Failure: > test_readable?(TestGemPath) [./test/rubygems/test_gem_path.rb:39]: > File no longer thinks > C:/Users/djberge/AppData/Local/Temp/test_rubygems_956 is readable > > 15) Failure: > test_writable?(TestGemPath) [./test/rubygems/test_gem_path.rb:53]: > File no longer thinks > C:/Users/djberge/AppData/Local/Temp/test_rubygems_956 is writable > > Plus a bunch of warnings at the end: > > 861 tests, 2830 assertions, 2 failures, 3 errors, 18 skips > ./lib/rubygems/test_case.rb:32: warning: redefine searcher= > ./lib/rubygems/test_case.rb:40: warning: redefine source_index= > ./lib/rubygems/test_case.rb:48: warning: redefine win_platform= > ./lib/rubygems/test_case.rb:56: warning: redefine ruby= > ./lib/rubygems/test_case.rb:97: warning: method redefined; discarding old setup > ./lib/rubygems/test_case.rb:197: warning: method redefined; discarding > old teardown > ./lib/rubygems/test_case.rb:229: warning: method redefined; discarding > old install_gem > ./lib/rubygems/test_case.rb:245: warning: method redefined; discarding > old uninstall_gem > ./lib/rubygems/test_case.rb:256: warning: method redefined; discarding > old create_tmpdir > ./lib/rubygems/test_case.rb:267: warning: method redefined; discarding old mu_pp > ./lib/rubygems/test_case.rb:277: warning: method redefined; discarding > old read_cache > ./lib/rubygems/test_case.rb:286: warning: method redefined; discarding > old read_binary > ./lib/rubygems/test_case.rb:293: warning: method redefined; discarding > old write_file > ./lib/rubygems/test_case.rb:316: warning: method redefined; discarding > old quick_gem > ./lib/rubygems/test_case.rb:344: warning: method redefined; discarding > old quick_spec > ./lib/rubygems/test_case.rb:372: warning: method redefined; discarding > old util_build_gem > ./lib/rubygems/test_case.rb:395: warning: method redefined; discarding > old util_clear_gems > ./lib/rubygems/test_case.rb:404: warning: method redefined; discarding > old install_specs > ./lib/rubygems/test_case.rb:416: warning: method redefined; discarding > old new_spec > ./lib/rubygems/test_case.rb:436: warning: method redefined; discarding > old util_spec > ./lib/rubygems/test_case.rb:456: warning: method redefined; discarding > old util_gem > ./lib/rubygems/test_case.rb:485: warning: method redefined; discarding > old util_gzip > ./lib/rubygems/test_case.rb:513: warning: method redefined; discarding > old util_make_gems > ./lib/rubygems/test_case.rb:573: warning: method redefined; discarding > old util_set_arch > ./lib/rubygems/test_case.rb:589: warning: method redefined; discarding > old util_setup_fake_fetche > ./lib/rubygems/test_case.rb:619: warning: method redefined; discarding > old util_setup_spec_fetche > ./lib/rubygems/test_case.rb:656: warning: method redefined; discarding > old util_zip > ./lib/rubygems/test_case.rb:663: warning: redefine win_platform? > ./lib/rubygems/test_case.rb:670: warning: method redefined; discarding > old win_platform? > ./lib/rubygems/test_case.rb:678: warning: redefine vc_windows? > ./lib/rubygems/test_case.rb:686: warning: method redefined; discarding > old vc_windows? > ./lib/rubygems/test_case.rb:695: warning: redefine make_command > ./lib/rubygems/test_case.rb:704: warning: method redefined; discarding > old make_command > ./lib/rubygems/test_case.rb:711: warning: method redefined; discarding > old nmake_found? > ./lib/rubygems/test_case.rb:720: warning: redefine process_based_port > ./lib/rubygems/test_case.rb:727: warning: method redefined; discarding > old process_based_port > ./lib/rubygems/test_case.rb:734: warning: method redefined; discarding > old build_rake_in > ./lib/rubygems/test_case.rb:752: warning: redefine rubybin > ./lib/rubygems/test_case.rb:792: warning: method redefined; discarding old dep > ./lib/rubygems/test_case.rb:799: warning: method redefined; discarding old req > ./lib/rubygems/test_case.rb:807: warning: method redefined; discarding old spec > ./lib/rubygems/test_case.rb:814: warning: method redefined; discarding old v > ./lib/rubygems/test_utilities.rb:29: warning: method redefined; > discarding old initialize > ./lib/rubygems/test_utilities.rb:34: warning: method redefined; > discarding old find_data > ./lib/rubygems/test_utilities.rb:46: warning: method redefined; > discarding old fetch_path > ./lib/rubygems/test_utilities.rb:61: warning: method redefined; > discarding old open_uri_or_path > ./lib/rubygems/test_utilities.rb:71: warning: method redefined; > discarding old request > ./lib/rubygems/test_utilities.rb:84: warning: method redefined; > discarding old fetch_size > ./lib/rubygems/test_utilities.rb:99: warning: method redefined; > discarding old download > ./lib/rubygems/test_utilities.rb:116: warning: method redefined; > discarding old download_to_cache > ./lib/rubygems/test_utilities.rb:131: warning: redefine fetcher= > ./lib/rubygems/test_utilities.rb:145: warning: method redefined; > discarding old initialize > ./lib/rubygems/test_utilities.rb:152: warning: method redefined; > discarding old string > > Regards, > > Dan > _______________________________________________ > Rubygems-developers mailing list > http://rubyforge.org/projects/rubygems > Rubygems-developers at rubyforge.org > http://rubyforge.org/mailman/listinfo/rubygems-developers From noreply at rubyforge.org Wed Apr 6 10:28:56 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 6 Apr 2011 10:28:56 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29120 ] updating rubygems from 1.6.2 to 1.7.x leads to error in rails 2.3.5 appliaction Message-ID: <20110406142856.9EF6A1858377@rubyforge.org> Bugs item #29120, was opened at 2011-04-06 16:28 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29120&group_id=126 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Peter Schr?der (phoet) Assigned to: Nobody (None) Summary: updating rubygems from 1.6.2 to 1.7.x leads to error in rails 2.3.5 appliaction Initial Comment: hi, we are currently not able to upgrade to latest rubygems, because of this error: /Users/peterschroder/.rvm/rubies/ree-1.8.7-2010.02/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:320:in `refresh!': source index not created from disk (RuntimeError) from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/rails-2.3.5/lib/rails/vendor_gem_source_index.rb:34:in `refresh!' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/rails-2.3.5/lib/rails/vendor_gem_source_index.rb:29:in `initialize' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/rails-2.3.5/lib/rails/gem_dependency.rb:21:in `new' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/rails-2.3.5/lib/rails/gem_dependency.rb:21:in `add_frozen_gem_path' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/rails-2.3.5/lib/initializer.rb:298:in `add_gem_load_paths' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/rails-2.3.5/lib/initializer.rb:132:in `process' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/rails-2.3.5/lib/initializer.rb:113:in `send' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/rails-2.3.5/lib/initializer.rb:113:in `run' from /Users/peterschroder/Sites/main/app/config/environment.rb:25 from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/activesupport-2.3.5/lib/active_support/dependencies.rb:156:in `require' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/activesupport-2.3.5/lib/active_support/dependencies.rb:156:in `require' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/activesupport-2.3.5/lib/active_support/dependencies.rb:521:in `new_constants_in' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/activesupport-2.3.5/lib/active_support/dependencies.rb:156:in `require' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/rails-2.3.5/lib/commands/server.rb:84 from script/server:3:in `require' from script/server:3 environemnt.rb:25 is just the rails-initializer: Rails::Initializer.run do |config| ... do you have any idea of where this error might come from? kind regards, peter ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29120&group_id=126 From djberg96 at gmail.com Thu Apr 7 00:39:43 2011 From: djberg96 at gmail.com (Daniel Berger) Date: Wed, 06 Apr 2011 22:39:43 -0600 Subject: [Rubygems-developers] Latest rubygems test results on Windows In-Reply-To: <18568D59-7754-4162-AA7B-3D7468EEBC45@hollensbe.org> References: <18568D59-7754-4162-AA7B-3D7468EEBC45@hollensbe.org> Message-ID: <4D9D400F.9060508@gmail.com> Hi, That seemed to fix it for Windows 7, thanks. Though, the warnings are still there. Regards, Dan On 4/6/11 1:36 AM, Erik Hollensbe wrote: > git clone git://github.com/erikh/rubygems From erik at hollensbe.org Thu Apr 7 00:48:21 2011 From: erik at hollensbe.org (Erik Hollensbe) Date: Thu, 7 Apr 2011 00:48:21 -0400 Subject: [Rubygems-developers] Latest rubygems test results on Windows In-Reply-To: <4D9D400F.9060508@gmail.com> References: <18568D59-7754-4162-AA7B-3D7468EEBC45@hollensbe.org> <4D9D400F.9060508@gmail.com> Message-ID: <3142F212-7E34-41A3-95A8-DC88253A961B@hollensbe.org> On Apr 7, 2011, at 12:39 AM, Daniel Berger wrote: > Hi, > > That seemed to fix it for Windows 7, thanks. Though, the warnings are still there. Yep, those happen in *nix too, and only for 1.8. I think it's something unrelated, as it's been there for a while now. -Erik From erik at hollensbe.org Thu Apr 7 04:27:52 2011 From: erik at hollensbe.org (Erik Hollensbe) Date: Thu, 7 Apr 2011 04:27:52 -0400 Subject: [Rubygems-developers] latest Gem::Path conversions Message-ID: <0B497558-BB49-46FA-8A58-1050901C774A@hollensbe.org> Dan's bugs are fixed + Specification has been converted to use Gem::Path. I took care to ensure that no external API changes occurred, but please validate. Tests pass on 1.8.7-p334 and 1.9.2-p180, OS X 10.6. While I can test on more platforms, help is always appreciated. Patches here: git://github.com/erikh/rubygems I'll investigate the double require of lib/rubygems/test_case as I get time (which is the cause of the warnings + second blank test run), but I don't think it's related to any of this work. Thanks for your time, -Erik From noreply at rubyforge.org Thu Apr 7 13:37:28 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 7 Apr 2011 13:37:28 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29120 ] updating rubygems from 1.6.2 to 1.7.x leads to error in rails 2.3.5 appliaction Message-ID: <20110407173728.2FC2E1858376@rubyforge.org> Bugs item #29120, was opened at 2011-04-06 07:28 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29120&group_id=126 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Peter Schr?der (phoet) Assigned to: Nobody (None) Summary: updating rubygems from 1.6.2 to 1.7.x leads to error in rails 2.3.5 appliaction Initial Comment: hi, we are currently not able to upgrade to latest rubygems, because of this error: /Users/peterschroder/.rvm/rubies/ree-1.8.7-2010.02/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:320:in `refresh!': source index not created from disk (RuntimeError) from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/rails-2.3.5/lib/rails/vendor_gem_source_index.rb:34:in `refresh!' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/rails-2.3.5/lib/rails/vendor_gem_source_index.rb:29:in `initialize' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/rails-2.3.5/lib/rails/gem_dependency.rb:21:in `new' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/rails-2.3.5/lib/rails/gem_dependency.rb:21:in `add_frozen_gem_path' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/rails-2.3.5/lib/initializer.rb:298:in `add_gem_load_paths' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/rails-2.3.5/lib/initializer.rb:132:in `process' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/rails-2.3.5/lib/initializer.rb:113:in `send' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/rails-2.3.5/lib/initializer.rb:113:in `run' from /Users/peterschroder/Sites/main/app/config/environment.rb:25 from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/activesupport-2.3.5/lib/active_support/dependencies.rb:156:in `require' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/activesupport-2.3.5/lib/active_support/dependencies.rb:156:in `require' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/activesupport-2.3.5/lib/active_support/dependencies.rb:521:in `new_constants_in' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/activesupport-2.3.5/lib/active_support/dependencies.rb:156:in `require' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/rails-2.3.5/lib/commands/server.rb:84 from script/server:3:in `require' from script/server:3 environemnt.rb:25 is just the rails-initializer: Rails::Initializer.run do |config| ... do you have any idea of where this error might come from? kind regards, peter ---------------------------------------------------------------------- >Comment By: Eric Hodel (drbrain) Date: 2011-04-07 10:37 Message: Does this happen with Rails 3? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29120&group_id=126 From djberg96 at gmail.com Thu Apr 7 17:41:03 2011 From: djberg96 at gmail.com (Daniel Berger) Date: Thu, 7 Apr 2011 15:41:03 -0600 Subject: [Rubygems-developers] rake test_functional Message-ID: Hi, rake test_functional (in /home/dberger/Repositories/rubygems-erikh) warning: couldn't activate the minitest plugin, skipping warning: couldn't activate the git plugin, skipping That's it. Any chance of adding some instructions on how those should be installed if they're not found? Or perhaps the task shouldn't be visible if they're not installed? Thanks, Dan From noreply at rubyforge.org Thu Apr 7 18:05:19 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 7 Apr 2011 18:05:19 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29120 ] updating rubygems from 1.6.2 to 1.7.x leads to error in rails 2.3.5 appliaction Message-ID: <20110407220519.C06941858300@rubyforge.org> Bugs item #29120, was opened at 2011-04-06 07:28 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29120&group_id=126 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Peter Schr?der (phoet) Assigned to: Nobody (None) Summary: updating rubygems from 1.6.2 to 1.7.x leads to error in rails 2.3.5 appliaction Initial Comment: hi, we are currently not able to upgrade to latest rubygems, because of this error: /Users/peterschroder/.rvm/rubies/ree-1.8.7-2010.02/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:320:in `refresh!': source index not created from disk (RuntimeError) from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/rails-2.3.5/lib/rails/vendor_gem_source_index.rb:34:in `refresh!' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/rails-2.3.5/lib/rails/vendor_gem_source_index.rb:29:in `initialize' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/rails-2.3.5/lib/rails/gem_dependency.rb:21:in `new' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/rails-2.3.5/lib/rails/gem_dependency.rb:21:in `add_frozen_gem_path' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/rails-2.3.5/lib/initializer.rb:298:in `add_gem_load_paths' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/rails-2.3.5/lib/initializer.rb:132:in `process' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/rails-2.3.5/lib/initializer.rb:113:in `send' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/rails-2.3.5/lib/initializer.rb:113:in `run' from /Users/peterschroder/Sites/main/app/config/environment.rb:25 from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/activesupport-2.3.5/lib/active_support/dependencies.rb:156:in `require' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/activesupport-2.3.5/lib/active_support/dependencies.rb:156:in `require' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/activesupport-2.3.5/lib/active_support/dependencies.rb:521:in `new_constants_in' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/activesupport-2.3.5/lib/active_support/dependencies.rb:156:in `require' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/rails-2.3.5/lib/commands/server.rb:84 from script/server:3:in `require' from script/server:3 environemnt.rb:25 is just the rails-initializer: Rails::Initializer.run do |config| ... do you have any idea of where this error might come from? kind regards, peter ---------------------------------------------------------------------- Comment By: Justin Dossey (jbd) Date: 2011-04-07 15:05 Message: I've reproduced this with Rails 2.3.10. I'm getting it with ruby 1.8.7, rubygems 1.7.2, bundler 1.0.11. It happens because there's nothing in Gem.source_index.spec_dirs at the time refresh! is called. A workaround (for me) is to comment out the line: @installed_source_index.refresh! in vendor_gem_source_index.rb. If your rails is in vendor/ that is pretty easy. ---------------------------------------------------------------------- Comment By: Eric Hodel (drbrain) Date: 2011-04-07 10:37 Message: Does this happen with Rails 3? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29120&group_id=126 From noreply at rubyforge.org Fri Apr 8 02:39:43 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 8 Apr 2011 02:39:43 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29120 ] updating rubygems from 1.6.2 to 1.7.x leads to error in rails 2.3.5 appliaction Message-ID: <20110408063943.510481858300@rubyforge.org> Bugs item #29120, was opened at 2011-04-06 16:28 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29120&group_id=126 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Peter Schr?der (phoet) Assigned to: Nobody (None) Summary: updating rubygems from 1.6.2 to 1.7.x leads to error in rails 2.3.5 appliaction Initial Comment: hi, we are currently not able to upgrade to latest rubygems, because of this error: /Users/peterschroder/.rvm/rubies/ree-1.8.7-2010.02/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:320:in `refresh!': source index not created from disk (RuntimeError) from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/rails-2.3.5/lib/rails/vendor_gem_source_index.rb:34:in `refresh!' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/rails-2.3.5/lib/rails/vendor_gem_source_index.rb:29:in `initialize' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/rails-2.3.5/lib/rails/gem_dependency.rb:21:in `new' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/rails-2.3.5/lib/rails/gem_dependency.rb:21:in `add_frozen_gem_path' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/rails-2.3.5/lib/initializer.rb:298:in `add_gem_load_paths' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/rails-2.3.5/lib/initializer.rb:132:in `process' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/rails-2.3.5/lib/initializer.rb:113:in `send' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/rails-2.3.5/lib/initializer.rb:113:in `run' from /Users/peterschroder/Sites/main/app/config/environment.rb:25 from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/activesupport-2.3.5/lib/active_support/dependencies.rb:156:in `require' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/activesupport-2.3.5/lib/active_support/dependencies.rb:156:in `require' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/activesupport-2.3.5/lib/active_support/dependencies.rb:521:in `new_constants_in' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/activesupport-2.3.5/lib/active_support/dependencies.rb:156:in `require' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/rails-2.3.5/lib/commands/server.rb:84 from script/server:3:in `require' from script/server:3 environemnt.rb:25 is just the rails-initializer: Rails::Initializer.run do |config| ... do you have any idea of where this error might come from? kind regards, peter ---------------------------------------------------------------------- Comment By: Hussein Morsy (husseinmorsy) Date: 2011-04-08 08:39 Message: Hi, same Problem with Rails 2.3.11 kind regards, hussein ---------------------------------------------------------------------- Comment By: Justin Dossey (jbd) Date: 2011-04-08 00:05 Message: I've reproduced this with Rails 2.3.10. I'm getting it with ruby 1.8.7, rubygems 1.7.2, bundler 1.0.11. It happens because there's nothing in Gem.source_index.spec_dirs at the time refresh! is called. A workaround (for me) is to comment out the line: @installed_source_index.refresh! in vendor_gem_source_index.rb. If your rails is in vendor/ that is pretty easy. ---------------------------------------------------------------------- Comment By: Eric Hodel (drbrain) Date: 2011-04-07 19:37 Message: Does this happen with Rails 3? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29120&group_id=126 From noreply at rubyforge.org Fri Apr 8 02:55:48 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 8 Apr 2011 02:55:48 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29120 ] updating rubygems from 1.6.2 to 1.7.x leads to error in rails 2.3.5 appliaction Message-ID: <20110408065548.8C5691858300@rubyforge.org> Bugs item #29120, was opened at 2011-04-06 16:28 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29120&group_id=126 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Peter Schr?der (phoet) Assigned to: Nobody (None) Summary: updating rubygems from 1.6.2 to 1.7.x leads to error in rails 2.3.5 appliaction Initial Comment: hi, we are currently not able to upgrade to latest rubygems, because of this error: /Users/peterschroder/.rvm/rubies/ree-1.8.7-2010.02/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:320:in `refresh!': source index not created from disk (RuntimeError) from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/rails-2.3.5/lib/rails/vendor_gem_source_index.rb:34:in `refresh!' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/rails-2.3.5/lib/rails/vendor_gem_source_index.rb:29:in `initialize' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/rails-2.3.5/lib/rails/gem_dependency.rb:21:in `new' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/rails-2.3.5/lib/rails/gem_dependency.rb:21:in `add_frozen_gem_path' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/rails-2.3.5/lib/initializer.rb:298:in `add_gem_load_paths' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/rails-2.3.5/lib/initializer.rb:132:in `process' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/rails-2.3.5/lib/initializer.rb:113:in `send' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/rails-2.3.5/lib/initializer.rb:113:in `run' from /Users/peterschroder/Sites/main/app/config/environment.rb:25 from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/activesupport-2.3.5/lib/active_support/dependencies.rb:156:in `require' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/activesupport-2.3.5/lib/active_support/dependencies.rb:156:in `require' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/activesupport-2.3.5/lib/active_support/dependencies.rb:521:in `new_constants_in' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/activesupport-2.3.5/lib/active_support/dependencies.rb:156:in `require' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/rails-2.3.5/lib/commands/server.rb:84 from script/server:3:in `require' from script/server:3 environemnt.rb:25 is just the rails-initializer: Rails::Initializer.run do |config| ... do you have any idea of where this error might come from? kind regards, peter ---------------------------------------------------------------------- Comment By: Hussein Morsy (husseinmorsy) Date: 2011-04-08 08:55 Message: A workaround for me is to downgraded to RubyGems 1.6.2 with gem update --system 1.6.2 ---------------------------------------------------------------------- Comment By: Hussein Morsy (husseinmorsy) Date: 2011-04-08 08:39 Message: Hi, same Problem with Rails 2.3.11 kind regards, hussein ---------------------------------------------------------------------- Comment By: Justin Dossey (jbd) Date: 2011-04-08 00:05 Message: I've reproduced this with Rails 2.3.10. I'm getting it with ruby 1.8.7, rubygems 1.7.2, bundler 1.0.11. It happens because there's nothing in Gem.source_index.spec_dirs at the time refresh! is called. A workaround (for me) is to comment out the line: @installed_source_index.refresh! in vendor_gem_source_index.rb. If your rails is in vendor/ that is pretty easy. ---------------------------------------------------------------------- Comment By: Eric Hodel (drbrain) Date: 2011-04-07 19:37 Message: Does this happen with Rails 3? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29120&group_id=126 From noreply at rubyforge.org Fri Apr 8 04:24:05 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 8 Apr 2011 04:24:05 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29120 ] updating rubygems from 1.6.2 to 1.7.x leads to error in rails 2.3.5 appliaction Message-ID: <20110408082408.594621858346@rubyforge.org> Bugs item #29120, was opened at 2011-04-06 07:28 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29120&group_id=126 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Peter Schr?der (phoet) >Assigned to: Ryan Davis (zenspider) Summary: updating rubygems from 1.6.2 to 1.7.x leads to error in rails 2.3.5 appliaction Initial Comment: hi, we are currently not able to upgrade to latest rubygems, because of this error: /Users/peterschroder/.rvm/rubies/ree-1.8.7-2010.02/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:320:in `refresh!': source index not created from disk (RuntimeError) from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/rails-2.3.5/lib/rails/vendor_gem_source_index.rb:34:in `refresh!' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/rails-2.3.5/lib/rails/vendor_gem_source_index.rb:29:in `initialize' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/rails-2.3.5/lib/rails/gem_dependency.rb:21:in `new' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/rails-2.3.5/lib/rails/gem_dependency.rb:21:in `add_frozen_gem_path' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/rails-2.3.5/lib/initializer.rb:298:in `add_gem_load_paths' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/rails-2.3.5/lib/initializer.rb:132:in `process' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/rails-2.3.5/lib/initializer.rb:113:in `send' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/rails-2.3.5/lib/initializer.rb:113:in `run' from /Users/peterschroder/Sites/main/app/config/environment.rb:25 from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/activesupport-2.3.5/lib/active_support/dependencies.rb:156:in `require' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/activesupport-2.3.5/lib/active_support/dependencies.rb:156:in `require' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/activesupport-2.3.5/lib/active_support/dependencies.rb:521:in `new_constants_in' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/activesupport-2.3.5/lib/active_support/dependencies.rb:156:in `require' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/rails-2.3.5/lib/commands/server.rb:84 from script/server:3:in `require' from script/server:3 environemnt.rb:25 is just the rails-initializer: Rails::Initializer.run do |config| ... do you have any idea of where this error might come from? kind regards, peter ---------------------------------------------------------------------- >Comment By: Ryan Davis (zenspider) Date: 2011-04-08 01:24 Message: The error is coming from bundler via their aptly named "cripple_rubygems" method. Justin's fix may work. I don't _think_ there are any negative repercussions to that approach except that you're modifying rails and it needs to be vendored. A more apt fix would be to add the following to your config/preinitialize.rb: module Bundler module SharedHelpers def cripple_rubygems(specs) warn "fuck you bundler..." end end end (of course, the "fuck you" line is optional... but it'll make ME happy if you leave it in) `rake environment` should be a sufficient test for my approach... That gets me past the error reported above... I didn't test further. But since I don't know why any of the hacks in cripple_rubygems exist in the first place, I can't say whether or not my approach has negative consequences. Oh, and I only tested against rails 2.3.11 + bundler 1.0.11 and rubygems 1.7.[1-2]. ---------------------------------------------------------------------- Comment By: Hussein Morsy (husseinmorsy) Date: 2011-04-07 23:55 Message: A workaround for me is to downgraded to RubyGems 1.6.2 with gem update --system 1.6.2 ---------------------------------------------------------------------- Comment By: Hussein Morsy (husseinmorsy) Date: 2011-04-07 23:39 Message: Hi, same Problem with Rails 2.3.11 kind regards, hussein ---------------------------------------------------------------------- Comment By: Justin Dossey (jbd) Date: 2011-04-07 15:05 Message: I've reproduced this with Rails 2.3.10. I'm getting it with ruby 1.8.7, rubygems 1.7.2, bundler 1.0.11. It happens because there's nothing in Gem.source_index.spec_dirs at the time refresh! is called. A workaround (for me) is to comment out the line: @installed_source_index.refresh! in vendor_gem_source_index.rb. If your rails is in vendor/ that is pretty easy. ---------------------------------------------------------------------- Comment By: Eric Hodel (drbrain) Date: 2011-04-07 10:37 Message: Does this happen with Rails 3? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29120&group_id=126 From noreply at rubyforge.org Fri Apr 8 05:12:48 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 8 Apr 2011 05:12:48 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29120 ] updating rubygems from 1.6.2 to 1.7.x leads to error in rails 2.3.5 appliaction Message-ID: <20110408091249.0F41D185834E@rubyforge.org> Bugs item #29120, was opened at 2011-04-06 16:28 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29120&group_id=126 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Peter Schr?der (phoet) Assigned to: Ryan Davis (zenspider) Summary: updating rubygems from 1.6.2 to 1.7.x leads to error in rails 2.3.5 appliaction Initial Comment: hi, we are currently not able to upgrade to latest rubygems, because of this error: /Users/peterschroder/.rvm/rubies/ree-1.8.7-2010.02/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:320:in `refresh!': source index not created from disk (RuntimeError) from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/rails-2.3.5/lib/rails/vendor_gem_source_index.rb:34:in `refresh!' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/rails-2.3.5/lib/rails/vendor_gem_source_index.rb:29:in `initialize' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/rails-2.3.5/lib/rails/gem_dependency.rb:21:in `new' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/rails-2.3.5/lib/rails/gem_dependency.rb:21:in `add_frozen_gem_path' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/rails-2.3.5/lib/initializer.rb:298:in `add_gem_load_paths' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/rails-2.3.5/lib/initializer.rb:132:in `process' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/rails-2.3.5/lib/initializer.rb:113:in `send' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/rails-2.3.5/lib/initializer.rb:113:in `run' from /Users/peterschroder/Sites/main/app/config/environment.rb:25 from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/activesupport-2.3.5/lib/active_support/dependencies.rb:156:in `require' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/activesupport-2.3.5/lib/active_support/dependencies.rb:156:in `require' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/activesupport-2.3.5/lib/active_support/dependencies.rb:521:in `new_constants_in' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/activesupport-2.3.5/lib/active_support/dependencies.rb:156:in `require' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/rails-2.3.5/lib/commands/server.rb:84 from script/server:3:in `require' from script/server:3 environemnt.rb:25 is just the rails-initializer: Rails::Initializer.run do |config| ... do you have any idea of where this error might come from? kind regards, peter ---------------------------------------------------------------------- >Comment By: Peter Schr?der (phoet) Date: 2011-04-08 11:12 Message: i will test monkey patching the cripple_rubygems method and report back. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-04-08 10:24 Message: The error is coming from bundler via their aptly named "cripple_rubygems" method. Justin's fix may work. I don't _think_ there are any negative repercussions to that approach except that you're modifying rails and it needs to be vendored. A more apt fix would be to add the following to your config/preinitialize.rb: module Bundler module SharedHelpers def cripple_rubygems(specs) warn "fuck you bundler..." end end end (of course, the "fuck you" line is optional... but it'll make ME happy if you leave it in) `rake environment` should be a sufficient test for my approach... That gets me past the error reported above... I didn't test further. But since I don't know why any of the hacks in cripple_rubygems exist in the first place, I can't say whether or not my approach has negative consequences. Oh, and I only tested against rails 2.3.11 + bundler 1.0.11 and rubygems 1.7.[1-2]. ---------------------------------------------------------------------- Comment By: Hussein Morsy (husseinmorsy) Date: 2011-04-08 08:55 Message: A workaround for me is to downgraded to RubyGems 1.6.2 with gem update --system 1.6.2 ---------------------------------------------------------------------- Comment By: Hussein Morsy (husseinmorsy) Date: 2011-04-08 08:39 Message: Hi, same Problem with Rails 2.3.11 kind regards, hussein ---------------------------------------------------------------------- Comment By: Justin Dossey (jbd) Date: 2011-04-08 00:05 Message: I've reproduced this with Rails 2.3.10. I'm getting it with ruby 1.8.7, rubygems 1.7.2, bundler 1.0.11. It happens because there's nothing in Gem.source_index.spec_dirs at the time refresh! is called. A workaround (for me) is to comment out the line: @installed_source_index.refresh! in vendor_gem_source_index.rb. If your rails is in vendor/ that is pretty easy. ---------------------------------------------------------------------- Comment By: Eric Hodel (drbrain) Date: 2011-04-07 19:37 Message: Does this happen with Rails 3? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29120&group_id=126 From noreply at rubyforge.org Fri Apr 8 12:06:45 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 8 Apr 2011 12:06:45 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29120 ] updating rubygems from 1.6.2 to 1.7.x leads to error in rails 2.3.5 appliaction Message-ID: <20110408160645.2C6AB1858346@rubyforge.org> Bugs item #29120, was opened at 2011-04-06 14:28 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29120&group_id=126 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Peter Schr?der (phoet) Assigned to: Ryan Davis (zenspider) Summary: updating rubygems from 1.6.2 to 1.7.x leads to error in rails 2.3.5 appliaction Initial Comment: hi, we are currently not able to upgrade to latest rubygems, because of this error: /Users/peterschroder/.rvm/rubies/ree-1.8.7-2010.02/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:320:in `refresh!': source index not created from disk (RuntimeError) from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/rails-2.3.5/lib/rails/vendor_gem_source_index.rb:34:in `refresh!' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/rails-2.3.5/lib/rails/vendor_gem_source_index.rb:29:in `initialize' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/rails-2.3.5/lib/rails/gem_dependency.rb:21:in `new' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/rails-2.3.5/lib/rails/gem_dependency.rb:21:in `add_frozen_gem_path' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/rails-2.3.5/lib/initializer.rb:298:in `add_gem_load_paths' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/rails-2.3.5/lib/initializer.rb:132:in `process' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/rails-2.3.5/lib/initializer.rb:113:in `send' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/rails-2.3.5/lib/initializer.rb:113:in `run' from /Users/peterschroder/Sites/main/app/config/environment.rb:25 from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/activesupport-2.3.5/lib/active_support/dependencies.rb:156:in `require' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/activesupport-2.3.5/lib/active_support/dependencies.rb:156:in `require' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/activesupport-2.3.5/lib/active_support/dependencies.rb:521:in `new_constants_in' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/activesupport-2.3.5/lib/active_support/dependencies.rb:156:in `require' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/rails-2.3.5/lib/commands/server.rb:84 from script/server:3:in `require' from script/server:3 environemnt.rb:25 is just the rails-initializer: Rails::Initializer.run do |config| ... do you have any idea of where this error might come from? kind regards, peter ---------------------------------------------------------------------- >Comment By: Evan Phoenix (evan) Date: 2011-04-08 16:06 Message: Changing the #cripple_rubygems may remove this error, but it will likely cause bundler to not work properly. I'll discuss with the bundler team about this bug today. ---------------------------------------------------------------------- Comment By: Peter Schr?der (phoet) Date: 2011-04-08 09:12 Message: i will test monkey patching the cripple_rubygems method and report back. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-04-08 08:24 Message: The error is coming from bundler via their aptly named "cripple_rubygems" method. Justin's fix may work. I don't _think_ there are any negative repercussions to that approach except that you're modifying rails and it needs to be vendored. A more apt fix would be to add the following to your config/preinitialize.rb: module Bundler module SharedHelpers def cripple_rubygems(specs) warn "fuck you bundler..." end end end (of course, the "fuck you" line is optional... but it'll make ME happy if you leave it in) `rake environment` should be a sufficient test for my approach... That gets me past the error reported above... I didn't test further. But since I don't know why any of the hacks in cripple_rubygems exist in the first place, I can't say whether or not my approach has negative consequences. Oh, and I only tested against rails 2.3.11 + bundler 1.0.11 and rubygems 1.7.[1-2]. ---------------------------------------------------------------------- Comment By: Hussein Morsy (husseinmorsy) Date: 2011-04-08 06:55 Message: A workaround for me is to downgraded to RubyGems 1.6.2 with gem update --system 1.6.2 ---------------------------------------------------------------------- Comment By: Hussein Morsy (husseinmorsy) Date: 2011-04-08 06:39 Message: Hi, same Problem with Rails 2.3.11 kind regards, hussein ---------------------------------------------------------------------- Comment By: Justin Dossey (jbd) Date: 2011-04-07 22:05 Message: I've reproduced this with Rails 2.3.10. I'm getting it with ruby 1.8.7, rubygems 1.7.2, bundler 1.0.11. It happens because there's nothing in Gem.source_index.spec_dirs at the time refresh! is called. A workaround (for me) is to comment out the line: @installed_source_index.refresh! in vendor_gem_source_index.rb. If your rails is in vendor/ that is pretty easy. ---------------------------------------------------------------------- Comment By: Eric Hodel (drbrain) Date: 2011-04-07 17:37 Message: Does this happen with Rails 3? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29120&group_id=126 From noreply at rubyforge.org Fri Apr 8 12:59:24 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 8 Apr 2011 12:59:24 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29120 ] updating rubygems from 1.6.2 to 1.7.x leads to error in rails 2.3.5 appliaction Message-ID: <20110408165925.0B4CC18581B2@rubyforge.org> Bugs item #29120, was opened at 2011-04-06 14:28 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29120&group_id=126 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Peter Schr?der (phoet) Assigned to: Ryan Davis (zenspider) Summary: updating rubygems from 1.6.2 to 1.7.x leads to error in rails 2.3.5 appliaction Initial Comment: hi, we are currently not able to upgrade to latest rubygems, because of this error: /Users/peterschroder/.rvm/rubies/ree-1.8.7-2010.02/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:320:in `refresh!': source index not created from disk (RuntimeError) from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/rails-2.3.5/lib/rails/vendor_gem_source_index.rb:34:in `refresh!' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/rails-2.3.5/lib/rails/vendor_gem_source_index.rb:29:in `initialize' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/rails-2.3.5/lib/rails/gem_dependency.rb:21:in `new' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/rails-2.3.5/lib/rails/gem_dependency.rb:21:in `add_frozen_gem_path' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/rails-2.3.5/lib/initializer.rb:298:in `add_gem_load_paths' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/rails-2.3.5/lib/initializer.rb:132:in `process' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/rails-2.3.5/lib/initializer.rb:113:in `send' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/rails-2.3.5/lib/initializer.rb:113:in `run' from /Users/peterschroder/Sites/main/app/config/environment.rb:25 from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/activesupport-2.3.5/lib/active_support/dependencies.rb:156:in `require' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/activesupport-2.3.5/lib/active_support/dependencies.rb:156:in `require' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/activesupport-2.3.5/lib/active_support/dependencies.rb:521:in `new_constants_in' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/activesupport-2.3.5/lib/active_support/dependencies.rb:156:in `require' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/rails-2.3.5/lib/commands/server.rb:84 from script/server:3:in `require' from script/server:3 environemnt.rb:25 is just the rails-initializer: Rails::Initializer.run do |config| ... do you have any idea of where this error might come from? kind regards, peter ---------------------------------------------------------------------- Comment By: Evan Phoenix (evan) Date: 2011-04-08 16:59 Message: This appears to be a simple bug in my recommended change for rubygems 1.7.0+ in bundler. I'm working with the bundler team to get a new release out ASAP. ---------------------------------------------------------------------- Comment By: Evan Phoenix (evan) Date: 2011-04-08 16:06 Message: Changing the #cripple_rubygems may remove this error, but it will likely cause bundler to not work properly. I'll discuss with the bundler team about this bug today. ---------------------------------------------------------------------- Comment By: Peter Schr?der (phoet) Date: 2011-04-08 09:12 Message: i will test monkey patching the cripple_rubygems method and report back. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-04-08 08:24 Message: The error is coming from bundler via their aptly named "cripple_rubygems" method. Justin's fix may work. I don't _think_ there are any negative repercussions to that approach except that you're modifying rails and it needs to be vendored. A more apt fix would be to add the following to your config/preinitialize.rb: module Bundler module SharedHelpers def cripple_rubygems(specs) warn "fuck you bundler..." end end end (of course, the "fuck you" line is optional... but it'll make ME happy if you leave it in) `rake environment` should be a sufficient test for my approach... That gets me past the error reported above... I didn't test further. But since I don't know why any of the hacks in cripple_rubygems exist in the first place, I can't say whether or not my approach has negative consequences. Oh, and I only tested against rails 2.3.11 + bundler 1.0.11 and rubygems 1.7.[1-2]. ---------------------------------------------------------------------- Comment By: Hussein Morsy (husseinmorsy) Date: 2011-04-08 06:55 Message: A workaround for me is to downgraded to RubyGems 1.6.2 with gem update --system 1.6.2 ---------------------------------------------------------------------- Comment By: Hussein Morsy (husseinmorsy) Date: 2011-04-08 06:39 Message: Hi, same Problem with Rails 2.3.11 kind regards, hussein ---------------------------------------------------------------------- Comment By: Justin Dossey (jbd) Date: 2011-04-07 22:05 Message: I've reproduced this with Rails 2.3.10. I'm getting it with ruby 1.8.7, rubygems 1.7.2, bundler 1.0.11. It happens because there's nothing in Gem.source_index.spec_dirs at the time refresh! is called. A workaround (for me) is to comment out the line: @installed_source_index.refresh! in vendor_gem_source_index.rb. If your rails is in vendor/ that is pretty easy. ---------------------------------------------------------------------- Comment By: Eric Hodel (drbrain) Date: 2011-04-07 17:37 Message: Does this happen with Rails 3? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29120&group_id=126 From noreply at rubyforge.org Fri Apr 8 15:25:12 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 8 Apr 2011 15:25:12 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29120 ] updating rubygems from 1.6.2 to 1.7.x leads to error in rails 2.3.5 appliaction Message-ID: <20110408192512.9D7881858300@rubyforge.org> Bugs item #29120, was opened at 2011-04-06 07:28 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29120&group_id=126 >Category: #gem and #require methods Group: None Status: Open >Resolution: Rejected Priority: 3 Submitted By: Peter Schr?der (phoet) Assigned to: Ryan Davis (zenspider) Summary: updating rubygems from 1.6.2 to 1.7.x leads to error in rails 2.3.5 appliaction Initial Comment: hi, we are currently not able to upgrade to latest rubygems, because of this error: /Users/peterschroder/.rvm/rubies/ree-1.8.7-2010.02/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:320:in `refresh!': source index not created from disk (RuntimeError) from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/rails-2.3.5/lib/rails/vendor_gem_source_index.rb:34:in `refresh!' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/rails-2.3.5/lib/rails/vendor_gem_source_index.rb:29:in `initialize' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/rails-2.3.5/lib/rails/gem_dependency.rb:21:in `new' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/rails-2.3.5/lib/rails/gem_dependency.rb:21:in `add_frozen_gem_path' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/rails-2.3.5/lib/initializer.rb:298:in `add_gem_load_paths' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/rails-2.3.5/lib/initializer.rb:132:in `process' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/rails-2.3.5/lib/initializer.rb:113:in `send' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/rails-2.3.5/lib/initializer.rb:113:in `run' from /Users/peterschroder/Sites/main/app/config/environment.rb:25 from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/activesupport-2.3.5/lib/active_support/dependencies.rb:156:in `require' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/activesupport-2.3.5/lib/active_support/dependencies.rb:156:in `require' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/activesupport-2.3.5/lib/active_support/dependencies.rb:521:in `new_constants_in' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/activesupport-2.3.5/lib/active_support/dependencies.rb:156:in `require' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/rails-2.3.5/lib/commands/server.rb:84 from script/server:3:in `require' from script/server:3 environemnt.rb:25 is just the rails-initializer: Rails::Initializer.run do |config| ... do you have any idea of where this error might come from? kind regards, peter ---------------------------------------------------------------------- >Comment By: Ryan Davis (zenspider) Date: 2011-04-08 12:25 Message: Evan, At this point, I don't care if we break bundler functionality as long as the blame goes where it belongs... As it stands, there are hundreds of tweets/blog posts about how rubygems has broken rails when that is clearly not the case. Also, was it demonstrated that removing cripple_rubygems actually causes problems? It was mostly written a long time ago, has essentially zero documentation as to WHY any of those hacks are needed, and generally looks like it is mostly wrong anyways. I think it should be emphasized that cripple_rubygems should be monotonically decreasing in size over time. Preferably by actually communicating with us as to what is needed. ---------------------------------------------------------------------- Comment By: Evan Phoenix (evan) Date: 2011-04-08 09:59 Message: This appears to be a simple bug in my recommended change for rubygems 1.7.0+ in bundler. I'm working with the bundler team to get a new release out ASAP. ---------------------------------------------------------------------- Comment By: Evan Phoenix (evan) Date: 2011-04-08 09:06 Message: Changing the #cripple_rubygems may remove this error, but it will likely cause bundler to not work properly. I'll discuss with the bundler team about this bug today. ---------------------------------------------------------------------- Comment By: Peter Schr?der (phoet) Date: 2011-04-08 02:12 Message: i will test monkey patching the cripple_rubygems method and report back. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-04-08 01:24 Message: The error is coming from bundler via their aptly named "cripple_rubygems" method. Justin's fix may work. I don't _think_ there are any negative repercussions to that approach except that you're modifying rails and it needs to be vendored. A more apt fix would be to add the following to your config/preinitialize.rb: module Bundler module SharedHelpers def cripple_rubygems(specs) warn "fuck you bundler..." end end end (of course, the "fuck you" line is optional... but it'll make ME happy if you leave it in) `rake environment` should be a sufficient test for my approach... That gets me past the error reported above... I didn't test further. But since I don't know why any of the hacks in cripple_rubygems exist in the first place, I can't say whether or not my approach has negative consequences. Oh, and I only tested against rails 2.3.11 + bundler 1.0.11 and rubygems 1.7.[1-2]. ---------------------------------------------------------------------- Comment By: Hussein Morsy (husseinmorsy) Date: 2011-04-07 23:55 Message: A workaround for me is to downgraded to RubyGems 1.6.2 with gem update --system 1.6.2 ---------------------------------------------------------------------- Comment By: Hussein Morsy (husseinmorsy) Date: 2011-04-07 23:39 Message: Hi, same Problem with Rails 2.3.11 kind regards, hussein ---------------------------------------------------------------------- Comment By: Justin Dossey (jbd) Date: 2011-04-07 15:05 Message: I've reproduced this with Rails 2.3.10. I'm getting it with ruby 1.8.7, rubygems 1.7.2, bundler 1.0.11. It happens because there's nothing in Gem.source_index.spec_dirs at the time refresh! is called. A workaround (for me) is to comment out the line: @installed_source_index.refresh! in vendor_gem_source_index.rb. If your rails is in vendor/ that is pretty easy. ---------------------------------------------------------------------- Comment By: Eric Hodel (drbrain) Date: 2011-04-07 10:37 Message: Does this happen with Rails 3? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29120&group_id=126 From noreply at rubyforge.org Fri Apr 8 15:25:43 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 8 Apr 2011 15:25:43 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29114 ] older gems interfere with loading paths from external gems Message-ID: <20110408192543.D9B801858300@rubyforge.org> Bugs item #29114, was opened at 2011-04-04 23:22 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29114&group_id=126 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Daniel DeLeo (danielsdeleo) >Assigned to: Eric Hodel (drbrain) Summary: older gems interfere with loading paths from external gems Initial Comment: I'm seeing this issue with the Chef project. In the current release version, we have a bunch of files under chef/knife/whatever.rb In the current prerelease version, we have plugin support using Gem.find_files (thanks for the patch guys!), so we've moved much of this code out to separate gems. We strip the paths we get back from Gem.find_files to the normal relative paths (e.g., chef/knife/ec2_server_create) so that we can uniq them and rely on rubygems to load the latest version of the gem. The problem I'm seeing is this: Chef 0.9.14 has a file 'chef/knife/ec2_instance_data' Chef 0.10.0 does not have this file. the knife-ec2 plugin *does* have a file 'chef/knife/ec2_instance_data' When I have both Chef 0.9.14 and Chef 0.10 installed and Chef 0.10 attempts to `require 'chef/knife/ec2_instance_data'` it gets a LoadError /Users/ddeleo/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:57:in `require': no such file to load -- chef/knife/ec2_instance_data (LoadError) from /Users/ddeleo/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:57:in `rescue in require' from /Users/ddeleo/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:35:in `require' from /Users/ddeleo/.rvm/gems/ruby-1.9.2-p180/gems/chef-0.10.0.beta.6/lib/chef/knife/core/subcommand_loader.rb:39:in `block in load_commands' # etc. If I run `gem which chef/knife/ec2_instance_data`, I see that rubygems prefers the one in the old version of chef: gem which chef/knife/ec2_instance_data /Users/ddeleo/.rvm/gems/ruby-1.9.2-p180/gems/chef-0.9.14/lib/chef/knife/ec2_instance_data.rb When I uninstall the old version of chef, so that I have only the 0.10 beta, then chef 0.10 can successfully require the 'chef/knife/ec2_instance_data' file, and `gem which` reports that the file is located in the knife-ec2 gem. ---------------------------------------------------------------------- Comment By: Daniel DeLeo (danielsdeleo) Date: 2011-04-04 23:27 Message: Forcing activation of the plugin gem (e.g., knife-ec2 in the example) works around the error, though extracting the gem name is messy to say the least. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29114&group_id=126 From noreply at rubyforge.org Fri Apr 8 15:25:52 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 8 Apr 2011 15:25:52 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29116 ] Mega slowness in custom require Message-ID: <20110408192552.AA5B41858300@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: 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 Fri Apr 8 15:30:12 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 8 Apr 2011 15:30:12 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29075 ] need for a post_install hook Message-ID: <20110408193013.084E01858300@rubyforge.org> Bugs item #29075, was opened at 2011-03-11 05:36 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29075&group_id=126 Category: `gem install` command (extensions) Group: next Status: Open Resolution: Rejected Priority: 3 Submitted By: Torsten Curdt (tcurdt) Assigned to: Ryan Davis (zenspider) Summary: need for a post_install hook Initial Comment: While there is Gem.post_install this cannot be used for gems that want to run some code on installation. In my particular case I need to compile some C++ code -a command line tool- that the gem depends on. It does not come with an extension though. Since there is no post_install hook exposed to the gem lifecycle people use the extconf for things like this. Since that one makes the assumption of building an extension, leaving out the create_makefile() results in Building native extensions. This could take a while... ERROR: Error installing ... ERROR: Failed to build gem native extension. No builder for extension 'path/to/extconf.rb' Which result in people doing things like this http://blog.costan.us/2008/11/post-install-post-update-scripts-for.html The best solution would certainly be to have some gem lifecyle hooks. But just making less assumption on the extension building would already be a first step. ---------------------------------------------------------------------- >Comment By: Ryan Davis (zenspider) Date: 2011-04-08 12:30 Message: Torsten, yeah. You just set your gemspec's extensions field to point to the Rakefile: s.extensions = ["notext/#{self.name}/Rakefile"] and the rakefile should work like below or however you want it to work... it's just rake so you can do anything you want. ---------------------------------------------------------------------- Comment By: Torsten Curdt (tcurdt) Date: 2011-03-15 00:02 Message: Ryan, can elaborate or point me to an example how to do a "rake-based extension"? IIUC this means providing a Rakefile (or Makefile?) instead of the generated by the extconf? Still have your test project around? ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-03-14 14:01 Message: Just to make sure I understand: you have a pure ruby gem that calls out to a binary that you want to provide (build and install) via the gem. If that is accurate, I don't think that extra post_install hooks are the right way to go here. I think you can make this work via "normal" mechanisms. I think what you want to do is design a rake-based extension but then have that rakefile build and install your binary instead of a shared library. I just simulated this with a simple hoe-based project that had 'notext/blah/Rakefile' as it's extension and that rakefile just had: task :default => :build task :build do puts "building my cmdline tool!" touch "happy" end Upon packaging and installing, 'happy' was created inside the notext dir of the install. ---------------------------------------------------------------------- Comment By: Torsten Curdt (tcurdt) Date: 2011-03-14 11:55 Message: You can turn it like you want but building binaries is what rubygems is already doing today. They just get a different linker treatment. Not sure why one make such hard distinction there. Abuse scenarios are a bogus argument as long as the extconf (or for that matter - any code from the gem) gets executed. ---------------------------------------------------------------------- Comment By: Marcus Rueckert (darix) Date: 2011-03-14 11:02 Message: and any packaging system that uses post install hooks for building files *is* broken. i didnt even refer to potential abuse scenarios yet, building native extensions for ruby is certainly in the scope of rubygems. building binaries that get installed somewhere definitely is not. ---------------------------------------------------------------------- Comment By: Torsten Curdt (tcurdt) Date: 2011-03-14 10:04 Message: If that binary was something that would make sense outside of the gem I would agree - but it doesn't. Following your arguments all native code should live somewhere else - including the normal extensions. That would add a complexity to the system I don't see worth having. A post_install hook certainly gives room for abuse but it's a common pattern found in the various packaging systems. Not sure I would call this a broken feature. In fact I think the current build in assumptions are even worse. ---------------------------------------------------------------------- Comment By: Marcus Rueckert (darix) Date: 2011-03-14 08:47 Message: imho this is just the wrong approach, intree packaging like that just sucks. for users as for packagers. maybe the user has your binary installed already just outside of $PATH? while you could walk over $PATH and check if a binary with the desired name exists, you couldnt be sure that behind the filename is really the app you are expecting and that the version is compatible. handle the absence of the binary properly in your code and document for the user that a certain binary is required for proper functioning of your gem. I would really object adding a broken feature like this. ---------------------------------------------------------------------- Comment By: Torsten Curdt (tcurdt) Date: 2011-03-14 08:07 Message: You are probably right. As long as it is tracked as feature or bug I am fine. Thanks - the short term thing works. It's just ugly :) ---------------------------------------------------------------------- Comment By: Jon Forums (jonforums) Date: 2011-03-14 08:04 Message: Fair. IMO this issue should reappear as a feature request rather than stay a bug. And that would likely lead to relooking at plugin/hook visibility. I don't know what Eric wants for next steps on this, but since he asked you to open the issue, maybe it's enough to leave it as a bug. Good luck with whatever short-term solution you choose. ---------------------------------------------------------------------- Comment By: Torsten Curdt (tcurdt) Date: 2011-03-14 07:22 Message: Sorry, but the --init is more a work around than really an option. IMO a post_install hook for a gem is quite a natural thing to expect. If that's not on the table extconf should at least not make all those assumptions people hack around today. If you just close this issue people will continue to abuse the extconf like I am doing, too now. IMO an empty extconf should just not result in an error and we would be OKish. ---------------------------------------------------------------------- Comment By: Jon Forums (jonforums) Date: 2011-03-14 06:51 Message: While you could go down the plugin/hook path and split things something like... https://github.com/jonforums/prething https://github.com/jonforums/thing I think it's a bad fit for what you're trying to do...could become a tarbaby trying to keep the `prething` plugin from affecting other gems and coordinating with your main gem. Try building/installing the `prething` and see how globally it affects RG ops. Probably faster and more robust to add an `--init` to your gem's `bin\somthing` executable and document your gem's two-step install process in a `Gem::Specification.post_install_message` and your project doc. Any reason to keep this listed as an open RG bug? ---------------------------------------------------------------------- Comment By: Jon Forums (jonforums) Date: 2011-03-12 07:18 Message: That snippet from our install script results in a rubygems/defaults/operating_system.rb file being generated similar to the following: # :DK-BEG: override 'gem install' to enable RubyInstaller DevKit usage Gem.pre_install do |gem_installer| unless gem_installer.spec.extensions.empty? unless ENV['PATH'].include?('C:\DevKit\mingw\bin') then Gem.ui.say 'Temporarily enhancing PATH to include DevKit...' if Gem.configuration.verbose ENV['PATH'] = 'C:\DevKit\bin;C:\DevKit\mingw\bin;' + ENV['PATH'] end ENV['RI_DEVKIT'] = 'C:\DevKit' ENV['CC'] = 'gcc' ENV['CPP'] = 'cpp' ENV['CXX'] = 'g++' end end # :DK-END While my usage is fairly simple and the only mildly clever parts are (a) checking whether a native extension is being installed, and (b) wrapping the code snippet in markers so I can manage non-clobbering/upgrades of existing operating_system.rb files, I'm still betting that you could use `system` to call out to your toolchain and build your C++ tool in a similar way. It's the combination of the filename/location in combination with the block to Gem.pre_install which sets the pre-install hook that RG calls at the appropriate time during an install. These two places in the source should help: https://github.com/rubygems/rubygems/blob/master/lib/rubygems.rb#L65-82 https://github.com/rubygems/rubygems/blob/master/lib/rubygems/installer.rb#L140 ---------------------------------------------------------------------- Comment By: Torsten Curdt (tcurdt) Date: 2011-03-12 02:55 Message: @Jon: Still don't quite understand when you are setting that hook. Why would that code be called on a 'gem install' ? ---------------------------------------------------------------------- Comment By: Jon Forums (jonforums) Date: 2011-03-11 08:05 Message: In the DevKit (MSYS/MinGW toolchain for Windows) subproject of the RubyInstaller we have a Ruby install script which dynamically builds a gem override script that uses the pre-install hook to setup the environment for building native gems on Windows using the DevKit: https://github.com/oneclick/rubyinstaller/blob/master/resources/devkit/dk.rb.erb#L46-65 Basically, it automagically brings the DevKit toolchain into the environment when doing something like `gem install bson_ext` Thinking out loud, but I wonder if you can do something similar but use `system` or `IO.popen` to optimistically compile your gem's C++ dependency before the install and abort if you get any errors. Might also want to check/cleanup in post-build. A wild-eyed idea, but it might work if you can split things into "pre-build dependencies" and "build extension" and abort if things go badly. ---------------------------------------------------------------------- Comment By: Torsten Curdt (tcurdt) Date: 2011-03-11 07:46 Message: Maybe I misunderstood but I think Eric said on IRC that the existing post_install is not for gems. Which is why he asked me to open this issue. Jon, can you give an example how that would work? Whether it is pre or post install is not important to me. It's just that one might want to build more than just extension on install. I got that working by abusing the extconf to execute my build and creating an empty Makefile. But that smells. ---------------------------------------------------------------------- Comment By: Jon Forums (jonforums) Date: 2011-03-11 07:13 Message: Can you split things up to use the pre-install and post-build hooks which as of 1.5.0 that can cancel gem installation...optimistically compile in the pre-install and abort if needed in either pre-install or post-build? http://blog.segment7.net/2011/01/31/rubygems-1-5 ---------------------------------------------------------------------- Comment By: Torsten Curdt (tcurdt) Date: 2011-03-11 05:54 Message: Then you also cannot allow native builds. Where is the difference? ---------------------------------------------------------------------- Comment By: Luis Lavena (luislavena) Date: 2011-03-11 05:44 Message: I would say no to this. Most of the users do not check what the gem do inside, so there is a huge potential of security risks on this. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29075&group_id=126 From noreply at rubyforge.org Fri Apr 8 15:36:16 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 8 Apr 2011 15:36:16 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-28931 ] RubyGems documentation is incomplete Message-ID: <20110408193616.6B7231858300@rubyforge.org> Bugs item #28931, was opened at 2011-02-15 13:55 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28931&group_id=126 Category: documentation Group: None >Status: Closed >Resolution: Rejected Priority: 3 Submitted By: V?t Ondruch (voxik) Assigned to: Eric Hodel (drbrain) Summary: RubyGems documentation is incomplete Initial Comment: Although Kernel#gem method is well documented in source code, its documentation does not appear neither in RDoc.info nor Rubygems official documentation. I tried to raise this issue in YARD's issue tracker (https://github.com/lsegal/yard/issues/closed/#issue/252) but I had been redirected here. Could you please fix this matter? I consider it very unfortunate when documentation cannot be read using appropriate tools. Vit ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-02-23 16:15 Message: This is a bug in rdoc ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28931&group_id=126 From noreply at rubyforge.org Fri Apr 8 16:30:07 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 8 Apr 2011 16:30:07 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29120 ] updating rubygems from 1.6.2 to 1.7.x leads to error in rails 2.3.5 appliaction Message-ID: <20110408203007.B6A201858300@rubyforge.org> Bugs item #29120, was opened at 2011-04-06 14:28 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29120&group_id=126 Category: #gem and #require methods Group: None Status: Open Resolution: Rejected Priority: 3 Submitted By: Peter Schr?der (phoet) Assigned to: Ryan Davis (zenspider) Summary: updating rubygems from 1.6.2 to 1.7.x leads to error in rails 2.3.5 appliaction Initial Comment: hi, we are currently not able to upgrade to latest rubygems, because of this error: /Users/peterschroder/.rvm/rubies/ree-1.8.7-2010.02/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:320:in `refresh!': source index not created from disk (RuntimeError) from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/rails-2.3.5/lib/rails/vendor_gem_source_index.rb:34:in `refresh!' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/rails-2.3.5/lib/rails/vendor_gem_source_index.rb:29:in `initialize' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/rails-2.3.5/lib/rails/gem_dependency.rb:21:in `new' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/rails-2.3.5/lib/rails/gem_dependency.rb:21:in `add_frozen_gem_path' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/rails-2.3.5/lib/initializer.rb:298:in `add_gem_load_paths' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/rails-2.3.5/lib/initializer.rb:132:in `process' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/rails-2.3.5/lib/initializer.rb:113:in `send' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/rails-2.3.5/lib/initializer.rb:113:in `run' from /Users/peterschroder/Sites/main/app/config/environment.rb:25 from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/activesupport-2.3.5/lib/active_support/dependencies.rb:156:in `require' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/activesupport-2.3.5/lib/active_support/dependencies.rb:156:in `require' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/activesupport-2.3.5/lib/active_support/dependencies.rb:521:in `new_constants_in' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/activesupport-2.3.5/lib/active_support/dependencies.rb:156:in `require' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/rails-2.3.5/lib/commands/server.rb:84 from script/server:3:in `require' from script/server:3 environemnt.rb:25 is just the rails-initializer: Rails::Initializer.run do |config| ... do you have any idea of where this error might come from? kind regards, peter ---------------------------------------------------------------------- >Comment By: Evan Phoenix (evan) Date: 2011-04-08 20:30 Message: Ryan, Agreed, I'll communicate to the world that the issue caused by me in bundler. And yes, I want cripple_rubygems to go away as well. I'm going to prioritize this and attempt to get it out of bundler as soon as I can. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-04-08 19:25 Message: Evan, At this point, I don't care if we break bundler functionality as long as the blame goes where it belongs... As it stands, there are hundreds of tweets/blog posts about how rubygems has broken rails when that is clearly not the case. Also, was it demonstrated that removing cripple_rubygems actually causes problems? It was mostly written a long time ago, has essentially zero documentation as to WHY any of those hacks are needed, and generally looks like it is mostly wrong anyways. I think it should be emphasized that cripple_rubygems should be monotonically decreasing in size over time. Preferably by actually communicating with us as to what is needed. ---------------------------------------------------------------------- Comment By: Evan Phoenix (evan) Date: 2011-04-08 16:59 Message: This appears to be a simple bug in my recommended change for rubygems 1.7.0+ in bundler. I'm working with the bundler team to get a new release out ASAP. ---------------------------------------------------------------------- Comment By: Evan Phoenix (evan) Date: 2011-04-08 16:06 Message: Changing the #cripple_rubygems may remove this error, but it will likely cause bundler to not work properly. I'll discuss with the bundler team about this bug today. ---------------------------------------------------------------------- Comment By: Peter Schr?der (phoet) Date: 2011-04-08 09:12 Message: i will test monkey patching the cripple_rubygems method and report back. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-04-08 08:24 Message: The error is coming from bundler via their aptly named "cripple_rubygems" method. Justin's fix may work. I don't _think_ there are any negative repercussions to that approach except that you're modifying rails and it needs to be vendored. A more apt fix would be to add the following to your config/preinitialize.rb: module Bundler module SharedHelpers def cripple_rubygems(specs) warn "fuck you bundler..." end end end (of course, the "fuck you" line is optional... but it'll make ME happy if you leave it in) `rake environment` should be a sufficient test for my approach... That gets me past the error reported above... I didn't test further. But since I don't know why any of the hacks in cripple_rubygems exist in the first place, I can't say whether or not my approach has negative consequences. Oh, and I only tested against rails 2.3.11 + bundler 1.0.11 and rubygems 1.7.[1-2]. ---------------------------------------------------------------------- Comment By: Hussein Morsy (husseinmorsy) Date: 2011-04-08 06:55 Message: A workaround for me is to downgraded to RubyGems 1.6.2 with gem update --system 1.6.2 ---------------------------------------------------------------------- Comment By: Hussein Morsy (husseinmorsy) Date: 2011-04-08 06:39 Message: Hi, same Problem with Rails 2.3.11 kind regards, hussein ---------------------------------------------------------------------- Comment By: Justin Dossey (jbd) Date: 2011-04-07 22:05 Message: I've reproduced this with Rails 2.3.10. I'm getting it with ruby 1.8.7, rubygems 1.7.2, bundler 1.0.11. It happens because there's nothing in Gem.source_index.spec_dirs at the time refresh! is called. A workaround (for me) is to comment out the line: @installed_source_index.refresh! in vendor_gem_source_index.rb. If your rails is in vendor/ that is pretty easy. ---------------------------------------------------------------------- Comment By: Eric Hodel (drbrain) Date: 2011-04-07 17:37 Message: Does this happen with Rails 3? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29120&group_id=126 From noreply at rubyforge.org Fri Apr 8 19:31:42 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 8 Apr 2011 19:31:42 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29120 ] updating rubygems from 1.6.2 to 1.7.x leads to error in rails 2.3.5 appliaction Message-ID: <20110408233142.A04961858346@rubyforge.org> Bugs item #29120, was opened at 2011-04-06 14:28 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29120&group_id=126 Category: #gem and #require methods Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Peter Schr?der (phoet) >Assigned to: Evan Phoenix (evan) Summary: updating rubygems from 1.6.2 to 1.7.x leads to error in rails 2.3.5 appliaction Initial Comment: hi, we are currently not able to upgrade to latest rubygems, because of this error: /Users/peterschroder/.rvm/rubies/ree-1.8.7-2010.02/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:320:in `refresh!': source index not created from disk (RuntimeError) from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/rails-2.3.5/lib/rails/vendor_gem_source_index.rb:34:in `refresh!' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/rails-2.3.5/lib/rails/vendor_gem_source_index.rb:29:in `initialize' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/rails-2.3.5/lib/rails/gem_dependency.rb:21:in `new' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/rails-2.3.5/lib/rails/gem_dependency.rb:21:in `add_frozen_gem_path' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/rails-2.3.5/lib/initializer.rb:298:in `add_gem_load_paths' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/rails-2.3.5/lib/initializer.rb:132:in `process' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/rails-2.3.5/lib/initializer.rb:113:in `send' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/rails-2.3.5/lib/initializer.rb:113:in `run' from /Users/peterschroder/Sites/main/app/config/environment.rb:25 from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/activesupport-2.3.5/lib/active_support/dependencies.rb:156:in `require' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/activesupport-2.3.5/lib/active_support/dependencies.rb:156:in `require' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/activesupport-2.3.5/lib/active_support/dependencies.rb:521:in `new_constants_in' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/activesupport-2.3.5/lib/active_support/dependencies.rb:156:in `require' from /Users/peterschroder/.rvm/gems/ree-1.8.7-2010.02 at app/gems/rails-2.3.5/lib/commands/server.rb:84 from script/server:3:in `require' from script/server:3 environemnt.rb:25 is just the rails-initializer: Rails::Initializer.run do |config| ... do you have any idea of where this error might come from? kind regards, peter ---------------------------------------------------------------------- >Comment By: Evan Phoenix (evan) Date: 2011-04-08 23:31 Message: This was a bug in bundler and should be fixed in 1.0.12 which is out today. I'm going to go ahead and close this ticket, please reopen if you still have an issue. ---------------------------------------------------------------------- Comment By: Evan Phoenix (evan) Date: 2011-04-08 20:30 Message: Ryan, Agreed, I'll communicate to the world that the issue caused by me in bundler. And yes, I want cripple_rubygems to go away as well. I'm going to prioritize this and attempt to get it out of bundler as soon as I can. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-04-08 19:25 Message: Evan, At this point, I don't care if we break bundler functionality as long as the blame goes where it belongs... As it stands, there are hundreds of tweets/blog posts about how rubygems has broken rails when that is clearly not the case. Also, was it demonstrated that removing cripple_rubygems actually causes problems? It was mostly written a long time ago, has essentially zero documentation as to WHY any of those hacks are needed, and generally looks like it is mostly wrong anyways. I think it should be emphasized that cripple_rubygems should be monotonically decreasing in size over time. Preferably by actually communicating with us as to what is needed. ---------------------------------------------------------------------- Comment By: Evan Phoenix (evan) Date: 2011-04-08 16:59 Message: This appears to be a simple bug in my recommended change for rubygems 1.7.0+ in bundler. I'm working with the bundler team to get a new release out ASAP. ---------------------------------------------------------------------- Comment By: Evan Phoenix (evan) Date: 2011-04-08 16:06 Message: Changing the #cripple_rubygems may remove this error, but it will likely cause bundler to not work properly. I'll discuss with the bundler team about this bug today. ---------------------------------------------------------------------- Comment By: Peter Schr?der (phoet) Date: 2011-04-08 09:12 Message: i will test monkey patching the cripple_rubygems method and report back. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-04-08 08:24 Message: The error is coming from bundler via their aptly named "cripple_rubygems" method. Justin's fix may work. I don't _think_ there are any negative repercussions to that approach except that you're modifying rails and it needs to be vendored. A more apt fix would be to add the following to your config/preinitialize.rb: module Bundler module SharedHelpers def cripple_rubygems(specs) warn "fuck you bundler..." end end end (of course, the "fuck you" line is optional... but it'll make ME happy if you leave it in) `rake environment` should be a sufficient test for my approach... That gets me past the error reported above... I didn't test further. But since I don't know why any of the hacks in cripple_rubygems exist in the first place, I can't say whether or not my approach has negative consequences. Oh, and I only tested against rails 2.3.11 + bundler 1.0.11 and rubygems 1.7.[1-2]. ---------------------------------------------------------------------- Comment By: Hussein Morsy (husseinmorsy) Date: 2011-04-08 06:55 Message: A workaround for me is to downgraded to RubyGems 1.6.2 with gem update --system 1.6.2 ---------------------------------------------------------------------- Comment By: Hussein Morsy (husseinmorsy) Date: 2011-04-08 06:39 Message: Hi, same Problem with Rails 2.3.11 kind regards, hussein ---------------------------------------------------------------------- Comment By: Justin Dossey (jbd) Date: 2011-04-07 22:05 Message: I've reproduced this with Rails 2.3.10. I'm getting it with ruby 1.8.7, rubygems 1.7.2, bundler 1.0.11. It happens because there's nothing in Gem.source_index.spec_dirs at the time refresh! is called. A workaround (for me) is to comment out the line: @installed_source_index.refresh! in vendor_gem_source_index.rb. If your rails is in vendor/ that is pretty easy. ---------------------------------------------------------------------- Comment By: Eric Hodel (drbrain) Date: 2011-04-07 17:37 Message: Does this happen with Rails 3? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29120&group_id=126 From erik at hollensbe.org Sat Apr 9 17:04:19 2011 From: erik at hollensbe.org (Erik Hollensbe) Date: Sat, 9 Apr 2011 17:04:19 -0400 Subject: [Rubygems-developers] figured out the double run in 1.8 Message-ID: <443B1EAC-1A67-4A4E-90DF-4E85FC06FC09@hollensbe.org> spec.testlib = :minitest Hoe requires 'test/unit' by default unless this is specified. :) It's in my master if people want to verify. Just in case I'm about to start a discussion needlessly, the test suite is littered with minitest references, so you're not going to be able to test rubygems without it anyhow. Aaaaaaand, test runs feel a bit faster as a result, and $" is MUCH smaller. -Erik From noreply at rubyforge.org Mon Apr 11 04:04:10 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 11 Apr 2011 04:04:10 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29075 ] need for a post_install hook Message-ID: <20110411080410.B4CB3167816A@rubyforge.org> Bugs item #29075, was opened at 2011-03-11 14:36 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29075&group_id=126 Category: `gem install` command (extensions) Group: next Status: Open Resolution: Rejected Priority: 3 Submitted By: Torsten Curdt (tcurdt) Assigned to: Ryan Davis (zenspider) Summary: need for a post_install hook Initial Comment: While there is Gem.post_install this cannot be used for gems that want to run some code on installation. In my particular case I need to compile some C++ code -a command line tool- that the gem depends on. It does not come with an extension though. Since there is no post_install hook exposed to the gem lifecycle people use the extconf for things like this. Since that one makes the assumption of building an extension, leaving out the create_makefile() results in Building native extensions. This could take a while... ERROR: Error installing ... ERROR: Failed to build gem native extension. No builder for extension 'path/to/extconf.rb' Which result in people doing things like this http://blog.costan.us/2008/11/post-install-post-update-scripts-for.html The best solution would certainly be to have some gem lifecyle hooks. But just making less assumption on the extension building would already be a first step. ---------------------------------------------------------------------- >Comment By: Torsten Curdt (tcurdt) Date: 2011-04-11 10:04 Message: Thanks, Ryan. If that's the case I think we can close this issue ...as soon as this is part of the documentation at least. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-04-08 21:30 Message: Torsten, yeah. You just set your gemspec's extensions field to point to the Rakefile: s.extensions = ["notext/#{self.name}/Rakefile"] and the rakefile should work like below or however you want it to work... it's just rake so you can do anything you want. ---------------------------------------------------------------------- Comment By: Torsten Curdt (tcurdt) Date: 2011-03-15 08:02 Message: Ryan, can elaborate or point me to an example how to do a "rake-based extension"? IIUC this means providing a Rakefile (or Makefile?) instead of the generated by the extconf? Still have your test project around? ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-03-14 22:01 Message: Just to make sure I understand: you have a pure ruby gem that calls out to a binary that you want to provide (build and install) via the gem. If that is accurate, I don't think that extra post_install hooks are the right way to go here. I think you can make this work via "normal" mechanisms. I think what you want to do is design a rake-based extension but then have that rakefile build and install your binary instead of a shared library. I just simulated this with a simple hoe-based project that had 'notext/blah/Rakefile' as it's extension and that rakefile just had: task :default => :build task :build do puts "building my cmdline tool!" touch "happy" end Upon packaging and installing, 'happy' was created inside the notext dir of the install. ---------------------------------------------------------------------- Comment By: Torsten Curdt (tcurdt) Date: 2011-03-14 19:55 Message: You can turn it like you want but building binaries is what rubygems is already doing today. They just get a different linker treatment. Not sure why one make such hard distinction there. Abuse scenarios are a bogus argument as long as the extconf (or for that matter - any code from the gem) gets executed. ---------------------------------------------------------------------- Comment By: Marcus Rueckert (darix) Date: 2011-03-14 19:02 Message: and any packaging system that uses post install hooks for building files *is* broken. i didnt even refer to potential abuse scenarios yet, building native extensions for ruby is certainly in the scope of rubygems. building binaries that get installed somewhere definitely is not. ---------------------------------------------------------------------- Comment By: Torsten Curdt (tcurdt) Date: 2011-03-14 18:04 Message: If that binary was something that would make sense outside of the gem I would agree - but it doesn't. Following your arguments all native code should live somewhere else - including the normal extensions. That would add a complexity to the system I don't see worth having. A post_install hook certainly gives room for abuse but it's a common pattern found in the various packaging systems. Not sure I would call this a broken feature. In fact I think the current build in assumptions are even worse. ---------------------------------------------------------------------- Comment By: Marcus Rueckert (darix) Date: 2011-03-14 16:47 Message: imho this is just the wrong approach, intree packaging like that just sucks. for users as for packagers. maybe the user has your binary installed already just outside of $PATH? while you could walk over $PATH and check if a binary with the desired name exists, you couldnt be sure that behind the filename is really the app you are expecting and that the version is compatible. handle the absence of the binary properly in your code and document for the user that a certain binary is required for proper functioning of your gem. I would really object adding a broken feature like this. ---------------------------------------------------------------------- Comment By: Torsten Curdt (tcurdt) Date: 2011-03-14 16:07 Message: You are probably right. As long as it is tracked as feature or bug I am fine. Thanks - the short term thing works. It's just ugly :) ---------------------------------------------------------------------- Comment By: Jon Forums (jonforums) Date: 2011-03-14 16:04 Message: Fair. IMO this issue should reappear as a feature request rather than stay a bug. And that would likely lead to relooking at plugin/hook visibility. I don't know what Eric wants for next steps on this, but since he asked you to open the issue, maybe it's enough to leave it as a bug. Good luck with whatever short-term solution you choose. ---------------------------------------------------------------------- Comment By: Torsten Curdt (tcurdt) Date: 2011-03-14 15:22 Message: Sorry, but the --init is more a work around than really an option. IMO a post_install hook for a gem is quite a natural thing to expect. If that's not on the table extconf should at least not make all those assumptions people hack around today. If you just close this issue people will continue to abuse the extconf like I am doing, too now. IMO an empty extconf should just not result in an error and we would be OKish. ---------------------------------------------------------------------- Comment By: Jon Forums (jonforums) Date: 2011-03-14 14:51 Message: While you could go down the plugin/hook path and split things something like... https://github.com/jonforums/prething https://github.com/jonforums/thing I think it's a bad fit for what you're trying to do...could become a tarbaby trying to keep the `prething` plugin from affecting other gems and coordinating with your main gem. Try building/installing the `prething` and see how globally it affects RG ops. Probably faster and more robust to add an `--init` to your gem's `bin\somthing` executable and document your gem's two-step install process in a `Gem::Specification.post_install_message` and your project doc. Any reason to keep this listed as an open RG bug? ---------------------------------------------------------------------- Comment By: Jon Forums (jonforums) Date: 2011-03-12 16:18 Message: That snippet from our install script results in a rubygems/defaults/operating_system.rb file being generated similar to the following: # :DK-BEG: override 'gem install' to enable RubyInstaller DevKit usage Gem.pre_install do |gem_installer| unless gem_installer.spec.extensions.empty? unless ENV['PATH'].include?('C:\DevKit\mingw\bin') then Gem.ui.say 'Temporarily enhancing PATH to include DevKit...' if Gem.configuration.verbose ENV['PATH'] = 'C:\DevKit\bin;C:\DevKit\mingw\bin;' + ENV['PATH'] end ENV['RI_DEVKIT'] = 'C:\DevKit' ENV['CC'] = 'gcc' ENV['CPP'] = 'cpp' ENV['CXX'] = 'g++' end end # :DK-END While my usage is fairly simple and the only mildly clever parts are (a) checking whether a native extension is being installed, and (b) wrapping the code snippet in markers so I can manage non-clobbering/upgrades of existing operating_system.rb files, I'm still betting that you could use `system` to call out to your toolchain and build your C++ tool in a similar way. It's the combination of the filename/location in combination with the block to Gem.pre_install which sets the pre-install hook that RG calls at the appropriate time during an install. These two places in the source should help: https://github.com/rubygems/rubygems/blob/master/lib/rubygems.rb#L65-82 https://github.com/rubygems/rubygems/blob/master/lib/rubygems/installer.rb#L140 ---------------------------------------------------------------------- Comment By: Torsten Curdt (tcurdt) Date: 2011-03-12 11:55 Message: @Jon: Still don't quite understand when you are setting that hook. Why would that code be called on a 'gem install' ? ---------------------------------------------------------------------- Comment By: Jon Forums (jonforums) Date: 2011-03-11 17:05 Message: In the DevKit (MSYS/MinGW toolchain for Windows) subproject of the RubyInstaller we have a Ruby install script which dynamically builds a gem override script that uses the pre-install hook to setup the environment for building native gems on Windows using the DevKit: https://github.com/oneclick/rubyinstaller/blob/master/resources/devkit/dk.rb.erb#L46-65 Basically, it automagically brings the DevKit toolchain into the environment when doing something like `gem install bson_ext` Thinking out loud, but I wonder if you can do something similar but use `system` or `IO.popen` to optimistically compile your gem's C++ dependency before the install and abort if you get any errors. Might also want to check/cleanup in post-build. A wild-eyed idea, but it might work if you can split things into "pre-build dependencies" and "build extension" and abort if things go badly. ---------------------------------------------------------------------- Comment By: Torsten Curdt (tcurdt) Date: 2011-03-11 16:46 Message: Maybe I misunderstood but I think Eric said on IRC that the existing post_install is not for gems. Which is why he asked me to open this issue. Jon, can you give an example how that would work? Whether it is pre or post install is not important to me. It's just that one might want to build more than just extension on install. I got that working by abusing the extconf to execute my build and creating an empty Makefile. But that smells. ---------------------------------------------------------------------- Comment By: Jon Forums (jonforums) Date: 2011-03-11 16:13 Message: Can you split things up to use the pre-install and post-build hooks which as of 1.5.0 that can cancel gem installation...optimistically compile in the pre-install and abort if needed in either pre-install or post-build? http://blog.segment7.net/2011/01/31/rubygems-1-5 ---------------------------------------------------------------------- Comment By: Torsten Curdt (tcurdt) Date: 2011-03-11 14:54 Message: Then you also cannot allow native builds. Where is the difference? ---------------------------------------------------------------------- Comment By: Luis Lavena (luislavena) Date: 2011-03-11 14:44 Message: I would say no to this. Most of the users do not check what the gem do inside, so there is a huge potential of security risks on this. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29075&group_id=126 From djberg96 at gmail.com Mon Apr 11 18:31:20 2011 From: djberg96 at gmail.com (Daniel Berger) Date: Mon, 11 Apr 2011 16:31:20 -0600 Subject: [Rubygems-developers] figured out the double run in 1.8 In-Reply-To: <443B1EAC-1A67-4A4E-90DF-4E85FC06FC09@hollensbe.org> References: <443B1EAC-1A67-4A4E-90DF-4E85FC06FC09@hollensbe.org> Message-ID: On Sat, Apr 9, 2011 at 3:04 PM, Erik Hollensbe wrote: > spec.testlib = :minitest > > Hoe requires 'test/unit' by default unless this is specified. :) It's in my master if people want to verify. > > Just in case I'm about to start a discussion needlessly, the test suite is littered with minitest references, so you're not going to be able to test rubygems without it anyhow. > > Aaaaaaand, test runs feel a bit faster as a result, and $" is MUCH smaller. I pulled the latest from your repo, but still get the double run. Dan From erik at hollensbe.org Mon Apr 11 18:39:16 2011 From: erik at hollensbe.org (Erik Hollensbe) Date: Mon, 11 Apr 2011 18:39:16 -0400 Subject: [Rubygems-developers] figured out the double run in 1.8 In-Reply-To: References: <443B1EAC-1A67-4A4E-90DF-4E85FC06FC09@hollensbe.org> Message-ID: <79CAAA1F-2260-4F27-AACF-730CF388A0D7@hollensbe.org> On Apr 11, 2011, at 6:31 PM, Daniel Berger wrote: > On Sat, Apr 9, 2011 at 3:04 PM, Erik Hollensbe wrote: >> spec.testlib = :minitest >> >> Hoe requires 'test/unit' by default unless this is specified. :) It's in my master if people want to verify. >> >> Just in case I'm about to start a discussion needlessly, the test suite is littered with minitest references, so you're not going to be able to test rubygems without it anyhow. >> >> Aaaaaaand, test runs feel a bit faster as a result, and $" is MUCH smaller. > > I pulled the latest from your repo, but still get the double run. > > Dan It was *just* changed like 10 minutes ago, long story. Try (for now) installing the hoe-seattlerb gem and see if you still get them. We're moving the appropriate plugin from that gem to the minitest gem proper, so hopefully that makes it a little less opaque. -Erik From noreply at rubyforge.org Mon Apr 11 20:21:03 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 11 Apr 2011 20:21:03 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29124 ] bad spec in ~/.gem/specs should be redownloaded instead of crashing Message-ID: <20110412002104.AB25C185834E@rubyforge.org> Bugs item #29124, was opened at 2011-04-12 00:21 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29124&group_id=126 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Ryan Cook (cookrn) Assigned to: Nobody (None) 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 drbrain at segment7.net Mon Apr 11 19:18:39 2011 From: drbrain at segment7.net (Eric Hodel) Date: Mon, 11 Apr 2011 16:18:39 -0700 Subject: [Rubygems-developers] rake test_functional In-Reply-To: References: Message-ID: On Apr 7, 2011, at 2:41 PM, Daniel Berger wrote: > Hi, > > rake test_functional > (in /home/dberger/Repositories/rubygems-erikh) > warning: couldn't activate the minitest plugin, skipping > warning: couldn't activate the git plugin, skipping > > That's it. > > Any chance of adding some instructions on how those should be > installed if they're not found? Or perhaps the task shouldn't be > visible if they're not installed? I think there's only one or two of functional tests left, they should be turned into regular tests. From drbrain at segment7.net Mon Apr 11 19:17:56 2011 From: drbrain at segment7.net (Eric Hodel) Date: Mon, 11 Apr 2011 16:17:56 -0700 Subject: [Rubygems-developers] has_rdoc deprecation and alternatives? In-Reply-To: <4D9BAB90.7050204@soen.ca> References: <4D9A1937.8000906@soen.ca> <3144FD33-9304-44CD-8CCF-B0247001AAE1@segment7.net> <4D9BAB90.7050204@soen.ca> Message-ID: <63E61171-D8D5-4448-A3EB-A8768C8DE60A@segment7.net> On Apr 5, 2011, at 4:53 PM, Loren Segal wrote: > On 4/5/2011 6:17 PM, Eric Hodel wrote: >> On Apr 4, 2011, at 12:17 PM, Loren Segal wrote: >> >>> ? the [has_rdoc] field has performed another task of differentiating gems with RDoc/YARD documentation for at least the last 2 years; at least with the addition of the YARD plugin. >> How does YARD fail when there's no special flag? > > We're basically monkeypatching the install_ri/install_rdoc functionality right now. If has_rdoc isn't set, YARD just silently lets RDoc do its thing without issue. The failure we had was because the Gem::Specification class was refactored to remove the overwrite_accessor feature, which we relied on. The new plugin code will throw out a standard attribute if that method is not present-- and, again, if that attribute stops getting checked, it should just fail gracefully. If you need a special flag why not have users add a file to the gem? I don't understand why yard has to be opt-in per-gem. Can't yard process any ruby project? That would make more sense to me. >>> 2. If extra bloat to gem package size is an issue with #1, perhaps we can give gem authors the ability to package these documentation files separately from the gem itself and push the documentation package independently of the gem (gem push_docs ?). >> I'm not fond of this as newer versions of rdoc (or yard) may fix bugs or add useful features that will Just Work on existing sources. > Well, by the same token, many versions of RDoc and YARD have bugs that cause problems for gems. For instance, we just (finally!) pulled in a change that fixes a really old bug in the RDoc shipped with 1.8.6 that causes parsing of YARD's code to fail: http://bit.ly/hyD9qu -- users with 1.8.6 (and there are a bunch) still report this error every now and then. Having static docs, we wouldn't have to deal with modifying anything in YARD's codebase and putting out another release just to fix the docs, we'd just need to push static docs. If you have a bug in your code that causes yard to fail how can you not need to release a new version? There aren't "a bunch" of 1.8.6 users. Over the last nine weeks 1.8% of downloads from rubygems.org were from ruby 1.8.6. There's a split of about 2/3 1.8.7 and 1/3 1.9.2 with less than 4% on 1.8.6, 1.9.1 or some other version. > Keep in mind this would also allow maintainers to package docs that are generated neither by rdoc or any other ruby doc tool-- ie. statically hand crafted docs. Although that might sound crazy, there are a handful of authors that might be interested in this capability. In fact, having run rubydoc.info for the last little while, we've actually gotten a few people asking if they could host static files on the site (unfortunately we can't) for this exact purpose. Some gem authors actually want to have extreme control over what their html docs look like, and perform post-processing on the html generated by tools like rdoc and yard, then host the docs on their own sites for this reason. IMO hosting static documentation is outside the scope of rubygems. Much of my documentation is hosted either on rubyforge under the project-specific hostname or docs.seattlerb.org. rubygems.org links to rubydoc.info by default but can be set to point wherever the user chooses. I am dubious of this proposal if it's a problem that rubydoc.info hasn't addressed. > Here are two more attempts at convincing you, and then I'll move on: > > The speed issue: again, generating the docs is slow. YARD is even slower than RDoc (although not by that much), so the tool is not the solution. Munging a bunch of HTML files is just a slow process. Users often want documentation locally, but don't necessarily want to wait 30-60 seconds to get it. I've actually gotten requests from users on where they can download the static rails docs that we host on rubydoc.info, so we made the package available. Why generate it yourself when you can download 400kb or even just a few MB of data? That's 60 seconds vs. 0.5-2 seconds; epic win. No tool can beat that. I'm pretty sure users would be drooling over something like this, and improve the amount of users actually bothering to install docs. Even *I* use --no-rdoc --no-ri because of speed issues. OTOH I wouldn't turn it off if it was just a static download away. Yes, yes, it's certainly anecdotal, but I'd wager that other users feel the same way. If so, more users getting the docs == a good thing. Having pre-built documentation in the gem is a no-go due to the size increase. It sounds like this should be a separate project that sits alongside rubygems.org like test.rubygems.org > Secondly, there are plugins and dependencies to deal with. YARD supports a variety of plugins, and increasingly, gem authors are making use of these. A gem author might use plugin X, but it isn't present on every user's system. Instead of adding a [potentially large] dependency on a gem *just to generate the docs*, it would be way better to just let the author have the dependencies on their system and not have the users worry about this. Consider this: Haml generates its YARD docs with `-m markdown --markup-provider maruku`, meaning it uses Markdown formatting through the Maruku library. This means to generate YARD docs on a `gem install haml`, it needs to first install maruku, which in turn depends on `syntax`. That's 2 extra gems just to generate the docs on the client side. All of this could be avoided by allowing the Haml guys to release a statically generated doc package. I'll bet RDoc might have similar issues with third party plugins. Sounds like haml isn't being very friendly to its users. Why do we need to do all this work in order to work around a gem author not making it easy to generate documentation? >> It's also an extra step that authors (that don't use Hoe) would have to implement. > > I'm not sure this extra step would be a big deal to most gem authors. It would be interesting to take a poll on this and see; I'd bet you'd get enormous support in favour of pre-built docs. Again, if the docs package isn't present, RubyGems can do the standard local generation it always has, with whatever tool is present, etc.. It would only be if this package was found that it would be fetched. This gives gem maintainers the *choice* to release static docs if they care and want their users to have fast installs. Polls are great, but often you'll find more people willing to say "I want X" than will say "I want to implement X" which will be more than say "I want to support X". With the new plugins as described below it is possible to implement this outside of rubygems itself and see how well it actually works. > I've never used hoe, nor do I use any variant of release-tool to package my gems, and I've had no issue. `gem build` and `gem push` is sufficient for me. If there was a `gem build_docs ` and `gem push `, that would be super easy to use. I don't see this as being a big barrier to entry; certainly not that complicated that you'd need to bring in a tool like hoe. I wonder if Nick knows anything about how complicated this would be to add from the Gemcutter side of things. I know I'm an outlier, but I've worked on nearly 80 gems and am actively working on about 10. An extra command to run (and remember to run) would be a pain. >>> 3. Add a `doc_bin` if none of the above are feasible. This would allow gem authors to specify the [Ruby] command to execute when installing a gem. >> I have an alternate solution: >> >> Add aadditional hook to the rubygems install sequence, pre_installs and post_installs (plural). For example: >> > *snip* >> There will also be a hook to change the default documentation set from %w[ri rdoc], probably on Gem.configuration > > I like this idea. You've just reminded me that I've wished the RubyGems plugin API had this functionality many many times. > > However, there are a few downsides with doing things this way: > > 1. It's still kind of important to allow gem authors to pick which tool their docs can be generated with. Again, some authors care a lot about what their docs look like, and this is problematic when a tool is not compatible with their documentation format. YARD formatting, for instance, doesn't look very good at all when generated by RDoc (or rocco, or tomdoc), and as a gem author I'd want the ability to opt out of the client using other tools, if yard was available. I'm guessing the authors who use YARD formatting in their docs would agree with this as well. I certainly understand that allowing the client to choose is important (give them overrides), but the authors should have a say, too. Don't you agree? I like the lead rubygems-test has taken on this, add a .gemtest file and rubygems-test will work. > 2. If a user was gem installing gemX that depended on yard, or some lib that used YARD formatting, their command `gem install --document=rdoc` would apply to both libs (right?). In other words, if gemX used RDoc formatting and the dependency did not, they'd be stuck generating the wrong type of docs for at least one of the libs. So again, there *is* some validity to making this a per-gem setting. Right, but they're more likely to specify --document=yard, which shouldn't be an issue, correct? If yard needs to care about falling-back properly it can call off to RDoc, right? > 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. From lsegal at soen.ca Tue Apr 12 15:20:45 2011 From: lsegal at soen.ca (Loren Segal) Date: Tue, 12 Apr 2011 15:20:45 -0400 Subject: [Rubygems-developers] has_rdoc deprecation and alternatives? In-Reply-To: <63E61171-D8D5-4448-A3EB-A8768C8DE60A@segment7.net> References: <4D9A1937.8000906@soen.ca> <3144FD33-9304-44CD-8CCF-B0247001AAE1@segment7.net> <4D9BAB90.7050204@soen.ca> <63E61171-D8D5-4448-A3EB-A8768C8DE60A@segment7.net> Message-ID: <4DA4A60D.7030804@soen.ca> On 4/11/2011 7:17 PM, Eric Hodel wrote: > If you need a special flag why not have users add a file to the gem? That's possible, and something we might have to do. The issue here is that there is already a perfectly valid field for this type of data. It just seems to me that making use of the gemspec is a much better place to store metadata than the filesystem. > I don't understand why yard has to be opt-in per-gem. Can't yard process any ruby project? That would make more sense to me. Yes and no. Yes, YARD is fairly compatible with standard natural language documentation and RDoc markup. At the same time, YARD doesn't support RDoc directives, and doesn't add as much value if the YARD syntax is not used. Let's ask the reverse question: Can't RDoc process any ruby project? The answer is similar. Sure, it can generate HTML files, but those HTML files would look pretty unreadable for a project like YARD, Haml or Datamapper, since RDoc doesn't support markdown, textile, or YARD formatting. Certainly many gem authors would not be happy with docs that did not generate properly on the client's machine. >>>> 2. If extra bloat to gem package size is an issue with #1, perhaps we can give gem authors the ability to package these documentation files separately from the gem itself and push the documentation package independently of the gem (gem push_docs ?). >>> I'm not fond of this as newer versions of rdoc (or yard) may fix bugs or add useful features that will Just Work on existing sources. >> Well, by the same token, many versions of RDoc and YARD have bugs that cause problems for gems. For instance, we just (finally!) pulled in a change that fixes a really old bug in the RDoc shipped with 1.8.6 that causes parsing of YARD's code to fail: http://bit.ly/hyD9qu -- users with 1.8.6 (and there are a bunch) still report this error every now and then. Having static docs, we wouldn't have to deal with modifying anything in YARD's codebase and putting out another release just to fix the docs, we'd just need to push static docs. > If you have a bug in your code that causes yard to fail how can you not need to release a new version? Perhaps you missed the issue? YARD is not failing, and the bug was not in our code. RDoc's generation of YARD documentation was failing in a stock 1.8.6 installation. We had to *work around* a bug in another codebase (RDoc) just to have docs work in a specific version of RDoc. With static generation, we would not need to care what RDoc the client had, since the files would be generated on our end (with our updated "bug-free" tools). > There aren't "a bunch" of 1.8.6 users. Over the last nine weeks 1.8% of downloads from rubygems.org were from ruby 1.8.6. I'm going by actual reports, not download statistics. We've had numerous reports about 1.8.6 issues, and still do. Keep in mind that 1.8.6 users are not all constantly downloading rubygems (in fact the whole issue here is that users did not update RDoc from the standard install)-- in fact many new gems dropped support for 1.8.6 (rack, rails) and in many cases they *can't* download new gems, so going by download counters is likely heavily skewed. >> Here are two more attempts at convincing you, and then I'll move on: >> >> The speed issue: again, generating the docs is slow. YARD is even slower than RDoc (although not by that much), so the tool is not the solution. Munging a bunch of HTML files is just a slow process. Users often want documentation locally, but don't necessarily want to wait 30-60 seconds to get it. I've actually gotten requests from users on where they can download the static rails docs that we host on rubydoc.info, so we made the package available. Why generate it yourself when you can download 400kb or even just a few MB of data? That's 60 seconds vs. 0.5-2 seconds; epic win. No tool can beat that. I'm pretty sure users would be drooling over something like this, and improve the amount of users actually bothering to install docs. Even *I* use --no-rdoc --no-ri because of speed issues. OTOH I wouldn't turn it off if it was just a static download away. Yes, yes, it's certainly anecdotal, but I'd wager that other users feel the same way. If so, more users getting the docs == a good thing. > Having pre-built documentation in the gem is a no-go due to the size increase. It sounds like this should be a separate project that sits alongside rubygems.org like test.rubygems.org Well that's precisely my point. I'm fine with hosting the docs in a separate package (and that's indeed what I've been suggesting); but to do this, it would need more integration. Creating a new gemspec just for docs would be hugely taxing on maintainers. Also releasing as a standard gem would make it unable to authors to update documentation files retroactively if there was a new RDoc tool or YARD tool that updated bugs / made the templates nicer. See above for a situation where a gem author might want to update documentation files. The gem release cycle doesn't fit perfectly with this system. >> Secondly, there are plugins and dependencies to deal with. YARD supports a variety of plugins, and increasingly, gem authors are making use of these. A gem author might use plugin X, but it isn't present on every user's system. Instead of adding a [potentially large] dependency on a gem *just to generate the docs*, it would be way better to just let the author have the dependencies on their system and not have the users worry about this. Consider this: Haml generates its YARD docs with `-m markdown --markup-provider maruku`, meaning it uses Markdown formatting through the Maruku library. This means to generate YARD docs on a `gem install haml`, it needs to first install maruku, which in turn depends on `syntax`. That's 2 extra gems just to generate the docs on the client side. All of this could be avoided by allowing the Haml guys to release a statically generated doc package. I'll bet RDoc might have similar issues with third party plugins. > Sounds like haml isn't being very friendly to its users. Why do we need to do all this work in order to work around a gem author not making it easy to generate documentation? Again, I think you're missing the point. Haml installs documentation just fine; the problem is that *to be friendly* to its users, its users need extra dependencies that they may never use again. Do you think it's reasonable to require every user of a gem to install "doc-tool", "doc-tool-plugin", "doc-tool-markup-X" just to get the docs? Perhaps the question should posed differently: why do *users* need to generate the documentation if the author can do it once for everybody? I still haven't really seen an answer to this one. It just seems more logical and efficient to me that docs be generated once and distributed to all rather than every user performing the same computation locally to create (hopefully!) the same end result. >> I've never used hoe, nor do I use any variant of release-tool to package my gems, and I've had no issue. `gem build` and `gem push` is sufficient for me. If there was a `gem build_docs` and `gem push`, that would be super easy to use. I don't see this as being a big barrier to entry; certainly not that complicated that you'd need to bring in a tool like hoe. I wonder if Nick knows anything about how complicated this would be to add from the Gemcutter side of things. > I know I'm an outlier, but I've worked on nearly 80 gems and am actively working on about 10. An extra command to run (and remember to run) would be a pain. I find this a little hard to believe. The extra command could be easily automated in a rake task or script. Users using gem packaging tools like jeweler or hoe could get this functionality virtually without thinking about it. Don't you use hoe? I can't imagine an extra command would be hard to add to that tool. >> 2. If a user was gem installing gemX that depended on yard, or some lib that used YARD formatting, their command `gem install --document=rdoc` would apply to both libs (right?). In other words, if gemX used RDoc formatting and the dependency did not, they'd be stuck generating the wrong type of docs for at least one of the libs. So again, there *is* some validity to making this a per-gem setting. > Right, but they're more likely to specify --document=yard, which shouldn't be an issue, correct? If yard needs to care about falling-back properly it can call off to RDoc, right? It might be an issue, see the first response on top. By the same token, they might call --document=rocco, or --document=tomdoc, which would definitely be an issue if a lib documented with YARD was pulled in as a dependency. We are not compatible with those tools at all. >> 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? - Loren From ryand-ruby at zenspider.com Tue Apr 12 21:57:43 2011 From: ryand-ruby at zenspider.com (Ryan Davis) Date: Tue, 12 Apr 2011 18:57:43 -0700 Subject: [Rubygems-developers] GemPathSearcher is dead RIPMF Message-ID: I just killed off GemPathSearcher. SourceIndex is next. Rawr. From ryand-ruby at zenspider.com Tue Apr 12 22:01:38 2011 From: ryand-ruby at zenspider.com (Ryan Davis) Date: Tue, 12 Apr 2011 19:01:38 -0700 Subject: [Rubygems-developers] rake test_functional In-Reply-To: References: Message-ID: On Apr 11, 2011, at 16:18 , Eric Hodel wrote: > On Apr 7, 2011, at 2:41 PM, Daniel Berger wrote: > >> Hi, >> >> rake test_functional >> (in /home/dberger/Repositories/rubygems-erikh) >> warning: couldn't activate the minitest plugin, skipping >> warning: couldn't activate the git plugin, skipping >> >> That's it. >> >> Any chance of adding some instructions on how those should be >> installed if they're not found? Or perhaps the task shouldn't be >> visible if they're not installed? > > I think there's only one or two of functional tests left, they should be turned into regular tests. WTF? We have functional tests? Nuking... From erik at hollensbe.org Tue Apr 12 22:56:17 2011 From: erik at hollensbe.org (Erik Hollensbe) Date: Tue, 12 Apr 2011 22:56:17 -0400 Subject: [Rubygems-developers] GemPathSearcher is dead RIPMF In-Reply-To: References: Message-ID: <15732BC9-87DA-48B4-8EA3-2D8E3A4F922C@hollensbe.org> On Apr 12, 2011, at 9:57 PM, Ryan Davis wrote: > I just killed off GemPathSearcher. > > SourceIndex is next. > > Rawr. Anything other than this? I've been porting these files gradually to Gem::Path. -Erik From ryand-ruby at zenspider.com Tue Apr 12 23:49:36 2011 From: ryand-ruby at zenspider.com (Ryan Davis) Date: Tue, 12 Apr 2011 20:49:36 -0700 Subject: [Rubygems-developers] rake test_functional In-Reply-To: References: Message-ID: <0B804F83-9B6A-415F-A7E2-08BBEBBFCE7A@zenspider.com> On Apr 12, 2011, at 19:01 , Ryan Davis wrote: > > WTF? We have functional tests? > > Nuking... that was a lot more painful than it should have been, but it is done. From erik at hollensbe.org Wed Apr 13 11:56:15 2011 From: erik at hollensbe.org (Erik Hollensbe) Date: Wed, 13 Apr 2011 11:56:15 -0400 Subject: [Rubygems-developers] GemPathSearcher is dead RIPMF In-Reply-To: <15732BC9-87DA-48B4-8EA3-2D8E3A4F922C@hollensbe.org> References: <15732BC9-87DA-48B4-8EA3-2D8E3A4F922C@hollensbe.org> Message-ID: <1926B510-3B66-43C4-BA9E-57D3A5AACE53@hollensbe.org> On Apr 12, 2011, at 10:56 PM, Erik Hollensbe wrote: > > On Apr 12, 2011, at 9:57 PM, Ryan Davis wrote: > >> I just killed off GemPathSearcher. >> >> SourceIndex is next. >> >> Rawr. > > > Anything other than this? I've been porting these files gradually to Gem::Path. Hello? -Erik From ryand-ruby at zenspider.com Thu Apr 14 15:07:46 2011 From: ryand-ruby at zenspider.com (Ryan Davis) Date: Thu, 14 Apr 2011 12:07:46 -0700 Subject: [Rubygems-developers] GemPathSearcher is dead RIPMF In-Reply-To: <15732BC9-87DA-48B4-8EA3-2D8E3A4F922C@hollensbe.org> References: <15732BC9-87DA-48B4-8EA3-2D8E3A4F922C@hollensbe.org> Message-ID: On Apr 12, 2011, at 19:56 , Erik Hollensbe wrote: > > On Apr 12, 2011, at 9:57 PM, Ryan Davis wrote: > >> I just killed off GemPathSearcher. >> >> SourceIndex is next. >> >> Rawr. > > > Anything other than this? I've been porting these files gradually to Gem::Path. Probably, but I can't tell you what they are yet... I'm deprecating anything that doesn't make sense or just plain sucks as I go along. I'm sure there is more. I'm trying to do GemPathSearcher and SourceIndex with little-to-no modification at all to them (I'm going to fail on SourceIndex because eventually it should feed off of Specification.all). From noreply at rubyforge.org Thu Apr 14 21:29:16 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 14 Apr 2011 21:29:16 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Feature Requests-29132 ] request: slightly cleaner "your ruby is too old" message Message-ID: <20110415012916.76A6F185834E@rubyforge.org> Feature Requests item #29132, was opened at 2011-04-15 01:29 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=578&aid=29132&group_id=126 Category: other Group: None Status: Open Resolution: None Priority: 3 Submitted By: Roger Pack (rogerdpack) Assigned to: Nobody (None) Summary: request: slightly cleaner "your ruby is too old" message Initial Comment: Hello. I noticed this the other day. rubygems-1.7.2 $ ruby setup.rb ./lib/rubygems/custom_require.rb:56:in `require': undefined method `end_with?' for "no such file to load -- Win32API":String (NoMethodError) Perhaps it could be made a bit more friendly. Cheers! -r ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=578&aid=29132&group_id=126 From transfire at gmail.com Thu Apr 14 23:02:51 2011 From: transfire at gmail.com (Trans) Date: Thu, 14 Apr 2011 20:02:51 -0700 (PDT) Subject: [Rubygems-developers] has_rdoc deprecation and alternatives? In-Reply-To: <4D9A1937.8000906@soen.ca> References: <4D9A1937.8000906@soen.ca> Message-ID: <009a1ec9-652b-402a-9ead-537bbe824ea5@f11g2000vbx.googlegroups.com> Bikeshed? Check out: https://github.com/rubygems/rubygems/pull/16 i.e. why have gem generate documentation? Let the doc server do it. From ryand-ruby at zenspider.com Sat Apr 16 19:22:00 2011 From: ryand-ruby at zenspider.com (Ryan Davis) Date: Sat, 16 Apr 2011 16:22:00 -0700 Subject: [Rubygems-developers] pushing up the pain aka deprecating SourceIndex Message-ID: <21117CC8-DE03-4040-B7E9-03E9657AF913@zenspider.com> For the last 4 days I've been hammering on rubygems to remove SourceIndex from internal usage. I'm most of the way there now and just pushed up my changes. I kinda expect stuff to break on people so I'm pushing early and often. With some minor exceptions, GemPathSearcher and SourceIndex are going to remain untouched. Their tests will be removed (or ported elsewhere) and their implementation will be removed 6ish months down the line. Current test runs are deprecation free, but some of that is because I've wrapped some stuff with Deprecation.skip_during {...}. Current Todo: + Remove extraneous skip_durings. + Add doco to the new methods in Dependency and Specification. + Port tests from SourceIndex to Dep/Spec. + Switch from SourceIndex.gems being the primary source to Specification.all. + Disallow regexps in dependency names. + Fix up my deprecations so they point to the new stuff when applicable. + Polish the turd. General Change Summary: Simple things should stay simple. Like: - matches = Gem.source_index.find_name(gem.name) + matches = Gem::Specification.find_by_name(gem.name) and: - specs = Gem.source_index.search dependency + specs = dependency.matching_specs # hey look! proper responsibilities! but harder things should get a bit harder: - specs = Gem.source_index.search dep + specs = Gem::Specification.find_all { |s| + s.name =~ name and req =~ s.version + } SourceIndex.search is a mess so I'm discontinuing the mess in favor of more transparent Enumerable usage. I'm sure there is more... but I need to study :D From lsegal at soen.ca Mon Apr 18 05:30:35 2011 From: lsegal at soen.ca (Loren Segal) Date: Mon, 18 Apr 2011 05:30:35 -0400 Subject: [Rubygems-developers] has_rdoc deprecation and alternatives? In-Reply-To: <4DA4A60D.7030804@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> Message-ID: <4DAC04BB.5010406@soen.ca> 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). - Loren From noreply at rubyforge.org Thu Apr 21 11:12:27 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 21 Apr 2011 11:12:27 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29141 ] Uninstaller fails when format-executable is set Message-ID: <20110421151227.D1B70185834E@rubyforge.org> Bugs item #29141, was opened at 2011-04-22 00: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: Open Resolution: None Priority: 3 Submitted By: Sakuro OZAWA (sakuro) Assigned to: Nobody (None) 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 Sat Apr 23 07:36:03 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 23 Apr 2011 07:36:03 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29145 ] Dynamically generated GemSpec.files ends up empty Message-ID: <20110423113603.3148618583AE@rubyforge.org> Bugs item #29145, was opened at 2011-04-23 13: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: Nobody (None) 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 erik at hollensbe.org Sat Apr 23 13:33:07 2011 From: erik at hollensbe.org (Erik Hollensbe) Date: Sat, 23 Apr 2011 13:33:07 -0400 Subject: [Rubygems-developers] rubinius and jruby test suite support Message-ID: I'm looking to ensure that rubinius and jruby are supported as first-class members in our test suite; I haven't gotten a response either way that's definitive. Is this an ok endeavor? It seems like it would be a healthy patchset so I'd like to ask first. Also, some notes on the suite as it stands in rubinius, pasted from IRC: 13:28:21 erikh | hrm... there has to be an implicit to_sym happening in rubinius' run of the test | suite 13:28:54 erikh | the codebase only has like ... 5 to_sym calls, and things breaks before the test | suite is even able to run... it's trying to coerce the .gemspec files. 13:29:06 erikh | I can't seem to find where that should be happening. 13:29:44 erikh | anyhow, adding a def to_sym; @path.to_sym; end to Gem::Path gets the test suite | limping along, but there are a lot of SSL and Fetcher related errors (very similar | to the ones seen when running against JRuby) Any kind of feedback on this would be great. Thanks! -Erik From headius at headius.com Mon Apr 25 15:30:13 2011 From: headius at headius.com (Charles Oliver Nutter) Date: Mon, 25 Apr 2011 14:30:13 -0500 Subject: [Rubygems-developers] rubinius and jruby test suite support In-Reply-To: References: Message-ID: I'd love to see JRuby have a regular CI test run against RubyGems. I believe we've managed in the past to have it almost 100% green, with just a few obscure failures. It definitely requires having jruby-openssl installed, as you'd expect, but I think a couple of us have spent time on the tests in the past. - Charlie On Sat, Apr 23, 2011 at 12:33 PM, Erik Hollensbe wrote: > I'm looking to ensure that rubinius and jruby are supported as first-class members in our test suite; I haven't gotten a response either way that's definitive. Is this an ok endeavor? It seems like it would be a healthy patchset so I'd like to ask first. > > Also, some notes on the suite as it stands in rubinius, pasted from IRC: > > > 13:28:21 erikh | hrm... there has to be an implicit to_sym happening in rubinius' run of the test > ? ? ? ? ? ? ? | suite > 13:28:54 erikh | the codebase only has like ... 5 to_sym calls, and things breaks before the test > ? ? ? ? ? ? ? | suite is even able to run... it's trying to coerce the .gemspec files. > 13:29:06 erikh | I can't seem to find where that should be happening. > 13:29:44 erikh | anyhow, adding a def to_sym; @path.to_sym; end to Gem::Path gets the test suite > ? ? ? ? ? ? ? | limping along, but there are a lot of SSL and Fetcher related errors (very similar > ? ? ? ? ? ? ? | to the ones seen when running against JRuby) > > Any kind of feedback on this would be great. Thanks! > > -Erik > _______________________________________________ > Rubygems-developers mailing list > http://rubyforge.org/projects/rubygems > Rubygems-developers at rubyforge.org > http://rubyforge.org/mailman/listinfo/rubygems-developers > From headius at headius.com Mon Apr 25 15:50:50 2011 From: headius at headius.com (Charles Oliver Nutter) Date: Mon, 25 Apr 2011 14:50:50 -0500 Subject: [Rubygems-developers] rubinius and jruby test suite support In-Reply-To: References: Message-ID: On Mon, Apr 25, 2011 at 2:30 PM, Charles Oliver Nutter wrote: > I'd love to see JRuby have a regular CI test run against RubyGems. I > believe we've managed in the past to have it almost 100% green, with > just a few obscure failures. It definitely requires having > jruby-openssl installed, as you'd expect, but I think a couple of us > have spent time on the tests in the past. Here's a run on my system with RubyGems 1.7.1 tag and JRuby master (mostly 1.6.1ish). https://gist.github.com/941050 Eleven F/E total for me... * Three seem to be SSL key issues. * Four look like this, and while I remember investigating before I obviously didn't find the problem: 3) Error: test_install_domain_both_no_network(TestGemDependencyInstaller): Gem::RemoteFetcher::FetchError: no data for http://gems.example.com/gems/a-1.gem (http://gems.example.com/gems/a-1.gem) * A few were checking the output of building an extension. JRuby warns when building extensions since that support is mostly experimental, so it didn't match without manual patching locally. The test should be fixed (see gist history to see it with the original errors in place). * A couple more appear to be subtle differences in the errors we report for some error conditions. The pkey failures are probably the biggest concern, but overall the suite is pretty close to green. - Charlie From erik at hollensbe.org Mon Apr 25 19:49:39 2011 From: erik at hollensbe.org (Erik Hollensbe) Date: Mon, 25 Apr 2011 19:49:39 -0400 Subject: [Rubygems-developers] rubinius and jruby test suite support In-Reply-To: References: Message-ID: <5443866C-2B61-4607-A6D7-E6BA1641DEC6@hollensbe.org> (Sorry for the top post) This sounds about like what I found; I'll be happy to correct these in rubygems proper, or at least remove them from testing under RUBY_PLATFORM =~ /java/. I definitely want to see what the fetcher issues are independently, they also fail in rubinius which makes me suspect some assumption that exists in MRI that isn't available elsewhere. Does anyone object to this? -Erik On Apr 25, 2011, at 3:50 PM, Charles Oliver Nutter wrote: > On Mon, Apr 25, 2011 at 2:30 PM, Charles Oliver Nutter > wrote: >> I'd love to see JRuby have a regular CI test run against RubyGems. I >> believe we've managed in the past to have it almost 100% green, with >> just a few obscure failures. It definitely requires having >> jruby-openssl installed, as you'd expect, but I think a couple of us >> have spent time on the tests in the past. > > Here's a run on my system with RubyGems 1.7.1 tag and JRuby master > (mostly 1.6.1ish). > > https://gist.github.com/941050 > > Eleven F/E total for me... > > * Three seem to be SSL key issues. > > * Four look like this, and while I remember investigating before I > obviously didn't find the problem: > > 3) Error: > test_install_domain_both_no_network(TestGemDependencyInstaller): > Gem::RemoteFetcher::FetchError: no data for > http://gems.example.com/gems/a-1.gem > (http://gems.example.com/gems/a-1.gem) > > * A few were checking the output of building an extension. JRuby warns > when building extensions since that support is mostly experimental, so > it didn't match without manual patching locally. The test should be > fixed (see gist history to see it with the original errors in place). > > * A couple more appear to be subtle differences in the errors we > report for some error conditions. > > The pkey failures are probably the biggest concern, but overall the > suite is pretty close to green. > > - Charlie > _______________________________________________ > Rubygems-developers mailing list > http://rubyforge.org/projects/rubygems > Rubygems-developers at rubyforge.org > http://rubyforge.org/mailman/listinfo/rubygems-developers From nakahiro at gmail.com Mon Apr 25 20:03:37 2011 From: nakahiro at gmail.com (Hiroshi Nakamura) Date: Tue, 26 Apr 2011 09:03:37 +0900 Subject: [Rubygems-developers] rubinius and jruby test suite support In-Reply-To: References: Message-ID: Hi all, For pkey issue, I need to push jruby-openssl 0.7.4 for jruby 1.6 compatibility. Safely ignored at this moment. Sorry for the problem. Regards, // NaHi On Apr 26, 2011 5:03 AM, "Charles Oliver Nutter" wrote: > On Mon, Apr 25, 2011 at 2:30 PM, Charles Oliver Nutter > wrote: >> I'd love to see JRuby have a regular CI test run against RubyGems. I >> believe we've managed in the past to have it almost 100% green, with >> just a few obscure failures. It definitely requires having >> jruby-openssl installed, as you'd expect, but I think a couple of us >> have spent time on the tests in the past. > > Here's a run on my system with RubyGems 1.7.1 tag and JRuby master > (mostly 1.6.1ish). > > https://gist.github.com/941050 > > Eleven F/E total for me... > > * Three seem to be SSL key issues. > > * Four look like this, and while I remember investigating before I > obviously didn't find the problem: > > 3) Error: > test_install_domain_both_no_network(TestGemDependencyInstaller): > Gem::RemoteFetcher::FetchError: no data for > http://gems.example.com/gems/a-1.gem > (http://gems.example.com/gems/a-1.gem) > > * A few were checking the output of building an extension. JRuby warns > when building extensions since that support is mostly experimental, so > it didn't match without manual patching locally. The test should be > fixed (see gist history to see it with the original errors in place). > > * A couple more appear to be subtle differences in the errors we > report for some error conditions. > > The pkey failures are probably the biggest concern, but overall the > suite is pretty close to green. > > - Charlie > _______________________________________________ > Rubygems-developers mailing list > http://rubyforge.org/projects/rubygems > Rubygems-developers at rubyforge.org > http://rubyforge.org/mailman/listinfo/rubygems-developers From headius at headius.com Mon Apr 25 21:06:19 2011 From: headius at headius.com (Charles Nutter) Date: Mon, 25 Apr 2011 20:06:19 -0500 Subject: [Rubygems-developers] rubinius and jruby test suite support In-Reply-To: <5443866C-2B61-4607-A6D7-E6BA1641DEC6@hollensbe.org> References: <5443866C-2B61-4607-A6D7-E6BA1641DEC6@hollensbe.org> Message-ID: All sounds great to me :) - Charlie (mobile) On Apr 25, 2011, at 18:49, Erik Hollensbe wrote: > (Sorry for the top post) > > This sounds about like what I found; I'll be happy to correct these in rubygems proper, or at least remove them from testing under RUBY_PLATFORM =~ /java/. > > I definitely want to see what the fetcher issues are independently, they also fail in rubinius which makes me suspect some assumption that exists in MRI that isn't available elsewhere. > > Does anyone object to this? > > -Erik > > On Apr 25, 2011, at 3:50 PM, Charles Oliver Nutter wrote: > >> On Mon, Apr 25, 2011 at 2:30 PM, Charles Oliver Nutter >> wrote: >>> I'd love to see JRuby have a regular CI test run against RubyGems. I >>> believe we've managed in the past to have it almost 100% green, with >>> just a few obscure failures. It definitely requires having >>> jruby-openssl installed, as you'd expect, but I think a couple of us >>> have spent time on the tests in the past. >> >> Here's a run on my system with RubyGems 1.7.1 tag and JRuby master >> (mostly 1.6.1ish). >> >> https://gist.github.com/941050 >> >> Eleven F/E total for me... >> >> * Three seem to be SSL key issues. >> >> * Four look like this, and while I remember investigating before I >> obviously didn't find the problem: >> >> 3) Error: >> test_install_domain_both_no_network(TestGemDependencyInstaller): >> Gem::RemoteFetcher::FetchError: no data for >> http://gems.example.com/gems/a-1.gem >> (http://gems.example.com/gems/a-1.gem) >> >> * A few were checking the output of building an extension. JRuby warns >> when building extensions since that support is mostly experimental, so >> it didn't match without manual patching locally. The test should be >> fixed (see gist history to see it with the original errors in place). >> >> * A couple more appear to be subtle differences in the errors we >> report for some error conditions. >> >> The pkey failures are probably the biggest concern, but overall the >> suite is pretty close to green. >> >> - Charlie >> _______________________________________________ >> Rubygems-developers mailing list >> http://rubyforge.org/projects/rubygems >> Rubygems-developers at rubyforge.org >> http://rubyforge.org/mailman/listinfo/rubygems-developers > > _______________________________________________ > Rubygems-developers mailing list > http://rubyforge.org/projects/rubygems > Rubygems-developers at rubyforge.org > http://rubyforge.org/mailman/listinfo/rubygems-developers