From schapht at gmail.com Sun Jun 1 10:20:01 2008 From: schapht at gmail.com (Mat Schaffer) Date: Sun, 1 Jun 2008 10:20:01 -0400 Subject: [Rubygems-developers] More unhappy memory usage on bulk update Message-ID: I'd like to bring back a discussion from http://rubyforge.org/pipermail/rubygems-developers/2007-May/002802.html I noticed that rubygems is now using Marshal for what should be faster loading, but I think I may have stumbled upon some sort of bug in that system. I edited the "say" statements in my rubygems to show whether they were coming from the site_ruby package or the 1.1.1 update gem. And also to output which index it was downloading and got this: $ sudo gem install rails Old Bulk updating Gem source index for: http://gems.rubyforge.org/ Loading Marshal.4.8.Z Old Bulk updating Gem source index for: http://gems.rubyforge.org/ Loading Marshal.4.8 Loading yaml.Z (Old == site_ruby installation) Then I commented out Marshal.4.8, yaml.Z and yaml from the list of options and got this: Old Bulk updating Gem source index for: http://gems.rubyforge.org/ Old Loading Marshal.4.8.Z Old Bulk updating Gem source index for: http://gems.rubyforge.org/ ERROR: While executing gem ... (Gem::RemoteSourceException) Error fetching remote gem cache: buffer error This is after letting it run all night because I only have a 256M slice and it looks like it needs quite a bit more than that to complete. Anyone have any thoughts as to why it appears to be restarting like this and not using the Marshal.4.8.Z download? Or if there's an easy way to get more debug info? And finally, have any of the developers considered some kind of solution that wouldn't require downloading the entire index? Thanks, Mat From ryand-ruby at zenspider.com Sun Jun 1 14:27:13 2008 From: ryand-ruby at zenspider.com (Ryan Davis) Date: Sun, 1 Jun 2008 11:27:13 -0700 Subject: [Rubygems-developers] More unhappy memory usage on bulk update In-Reply-To: References: Message-ID: <315F4BE7-5FED-4E72-B012-C90EB9983384@zenspider.com> On Jun 1, 2008, at 07:20 , Mat Schaffer wrote: > I'd like to bring back a discussion from http://rubyforge.org/pipermail/rubygems-developers/2007-May/002802.html bulk updating is being addressed in the next release. RSN. From schapht at gmail.com Sun Jun 1 14:34:05 2008 From: schapht at gmail.com (Mat Schaffer) Date: Sun, 1 Jun 2008 14:34:05 -0400 Subject: [Rubygems-developers] More unhappy memory usage on bulk update In-Reply-To: <315F4BE7-5FED-4E72-B012-C90EB9983384@zenspider.com> References: <315F4BE7-5FED-4E72-B012-C90EB9983384@zenspider.com> Message-ID: <136C18BD-6448-4AF0-94C9-A1EE691A2A5B@gmail.com> On Jun 1, 2008, at 2:27 PM, Ryan Davis wrote: > On Jun 1, 2008, at 07:20 , Mat Schaffer wrote: > >> I'd like to bring back a discussion from http://rubyforge.org/pipermail/rubygems-developers/2007-May/002802.html > > bulk updating is being addressed in the next release. RSN. Great, thanks! Looking forward to it. -Mat From drbrain at segment7.net Tue Jun 3 19:36:39 2008 From: drbrain at segment7.net (Eric Hodel) Date: Tue, 3 Jun 2008 16:36:39 -0700 Subject: [Rubygems-developers] HEADSUP RubyGems 1.2 Real Soon Now Message-ID: I believe RubyGems is currently feature-complete for the next release. For the next while I'll be focusing on bugfixes and patches from the tracker. I expect to release a new version in two weeks at minimum, possibly longer. 1.2 will longer perform bulk index updates. RubyGems now fetches individual specs as needed, so updating to the latest version of a gem will not require downloading gemspecs for unrelated gems. The new metadata updater required a new API, and RubyGems will fall into backwards compatibility mode for working with remote repositories that haven't updated to 1.2. Upon detecting a legacy repository, RubyGems will switch to legacy mode and continue. I haven't performed any tests of this code in the real world though, so I would like some assistance in that. I will no longer maintain Gem::SourceInfoCache or Gem::SourceInfoCacheEntry, and will instead encourage repository maintainers to update to RubyGems 1.2. There is some minor fallout from this change, `gem list -r -d` (list all gems with descriptions) is very slow currently since individual gemspecs must be fetched. If this is a real problem, I can come up with a solution to address it. Also, `gem dep -rR` (reverse dependencies for remote gems) is no longer supported. 1.2 now requires rubygems/defaults/operating_system.rb and rubygems/ defaults/#{RUBY_ENGINE}.rb if they exist to allow overrides to RubyGems defaults. Minor additions to various RubyGems APIs may be made due to feedback from JRuby or Rubinius to enhance support of this feature. 1.2 now features dependency types for dependent gems thanks to John Barnette. Current types are :runtime and :development, but I believe I will add :install (for passenger). From drnicwilliams at gmail.com Tue Jun 3 19:40:39 2008 From: drnicwilliams at gmail.com (Nic Williams) Date: Wed, 4 Jun 2008 09:40:39 +1000 Subject: [Rubygems-developers] HEADSUP RubyGems 1.2 Real Soon Now In-Reply-To: References: Message-ID: <44b555bb0806031640iad0fd11g59bbc183bbe0a0f0@mail.gmail.com> Yay for dependency types!! On Wed, Jun 4, 2008 at 9:36 AM, Eric Hodel wrote: > I believe RubyGems is currently feature-complete for the next release. For > the next while I'll be focusing on bugfixes and patches from the tracker. I > expect to release a new version in two weeks at minimum, possibly longer. > > 1.2 will longer perform bulk index updates. RubyGems now fetches > individual specs as needed, so updating to the latest version of a gem will > not require downloading gemspecs for unrelated gems. > > The new metadata updater required a new API, and RubyGems will fall into > backwards compatibility mode for working with remote repositories that > haven't updated to 1.2. Upon detecting a legacy repository, RubyGems will > switch to legacy mode and continue. I haven't performed any tests of this > code in the real world though, so I would like some assistance in that. > > I will no longer maintain Gem::SourceInfoCache or > Gem::SourceInfoCacheEntry, and will instead encourage repository maintainers > to update to RubyGems 1.2. > > There is some minor fallout from this change, `gem list -r -d` (list all > gems with descriptions) is very slow currently since individual gemspecs > must be fetched. If this is a real problem, I can come up with a solution > to address it. Also, `gem dep -rR` (reverse dependencies for remote gems) > is no longer supported. > > 1.2 now requires rubygems/defaults/operating_system.rb and > rubygems/defaults/#{RUBY_ENGINE}.rb if they exist to allow overrides to > RubyGems defaults. Minor additions to various RubyGems APIs may be made due > to feedback from JRuby or Rubinius to enhance support of this feature. > > 1.2 now features dependency types for dependent gems thanks to John > Barnette. Current types are :runtime and :development, but I believe I will > add :install (for passenger). > _______________________________________________ > Rubygems-developers mailing list > Rubygems-developers at rubyforge.org > http://rubyforge.org/mailman/listinfo/rubygems-developers > -- Dr Nic Williams * Learn TextMate for Rails2 - http://peepcode.com/products/textmate-for-rails-2 * Training in Ruby/Rails/JavaScript - http://drnicacademy.com Fun with Ruby/Rails/Javascript - http://drnicwilliams.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From jbarnette at gmail.com Tue Jun 3 20:28:18 2008 From: jbarnette at gmail.com (John Barnette) Date: Tue, 3 Jun 2008 17:28:18 -0700 Subject: [Rubygems-developers] HEADSUP RubyGems 1.2 Real Soon Now In-Reply-To: References: Message-ID: <2bce3eb60806031728g7e9ef38amf688ae8411a2b3c8@mail.gmail.com> On Tue, Jun 3, 2008 at 4:36 PM, Eric Hodel wrote: > 1.2 now features dependency types for dependent gems thanks to John > Barnette. Current types are :runtime and :development, but I believe I will > add :install (for passenger). When I committed, I couldn't remember the use case for :install, so Ryan and I removed it. Could you refresh my memory? ~ j. From avatar at spellboundnet.com Tue Jun 3 21:17:20 2008 From: avatar at spellboundnet.com (Donavan Pantke) Date: Tue, 3 Jun 2008 21:17:20 -0400 Subject: [Rubygems-developers] HEADSUP RubyGems 1.2 Real Soon Now In-Reply-To: <2bce3eb60806031728g7e9ef38amf688ae8411a2b3c8@mail.gmail.com> References: <2bce3eb60806031728g7e9ef38amf688ae8411a2b3c8@mail.gmail.com> Message-ID: <200806032117.21230.avatar@spellboundnet.com> On Tuesday 03 June 2008 08:28:18 pm John Barnette wrote: > On Tue, Jun 3, 2008 at 4:36 PM, Eric Hodel wrote: > > 1.2 now features dependency types for dependent gems thanks to John > > Barnette. Current types are :runtime and :development, but I believe I will > > add :install (for passenger). > > When I committed, I couldn't remember the use case for :install, so > Ryan and I removed it. Could you refresh my memory? The :install flag is required for gems that have specific loading requirements, and so cannot have dependencies automatically activated. The biggest use case is Passenger, which can activate multiple versions of Rails. It originally required rails in the gemspec (as it needs some version of Rails), but that meant that when the passenger gem activated, rails automatically activated as well. That caused passenger to blow up when trying to activate a different version of Rails. Having the :install flag will allow Passenger to be loaded but let Passenger worry about Rails. Thanks! Donavan > > > ~ j. > _______________________________________________ > Rubygems-developers mailing list > Rubygems-developers at rubyforge.org > http://rubyforge.org/mailman/listinfo/rubygems-developers > From jeremy at bitsweat.net Tue Jun 3 21:22:33 2008 From: jeremy at bitsweat.net (Jeremy Kemper) Date: Tue, 3 Jun 2008 18:22:33 -0700 Subject: [Rubygems-developers] HEADSUP RubyGems 1.2 Real Soon Now In-Reply-To: References: Message-ID: <69a2885c0806031822v3baed80bv78e30d60fb8310b7@mail.gmail.com> On Tue, Jun 3, 2008 at 4:36 PM, Eric Hodel wrote: > I believe RubyGems is currently feature-complete for the next release. For > the next while I'll be focusing on bugfixes and patches from the tracker. I > expect to release a new version in two weeks at minimum, possibly longer. I'd love to see little-known --format-executable enabled by default for gem installs. This gives you bin stubs that match your ruby name, e.g. rake-1.9 for ruby-1.9 and rake for ruby. Currently, both are installed as rake so the latest install clobbers the previous one. This is confusing and aggravating but few are aware that --format-executable solves it. Changing the default would be a welcome improvement in gem install experience for those working with multiple rubies and doesn't change behavior for the 95% who aren't. Plus, the 1.2 release is an auspicious opportunity to flip the switch just as 1.8.7 is out and 1.9.1 nears release. jeremy From bret at pettichord.com Tue Jun 3 21:30:35 2008 From: bret at pettichord.com (Bret Pettichord) Date: Tue, 3 Jun 2008 20:30:35 -0500 Subject: [Rubygems-developers] Help with Gem Dependencies Message-ID: I'd like to be able to improve the Watir installation process. Currently if you do a "gem install watir" you get this: C:\Documents and Settings\Majid_Home>gem install watir Install required dependency windows-pr? [Yn] Y Install required dependency windows-api? [Yn] Y Install required dependency win32-api? [Yn] Y Select which gem to install for your platform (i386-mswin32) 1. win32-api 1.0.6 (x86-mswin32-60) 2. win32-api 1.0.6 (ruby) 3. win32-api 1.0.5 (x86-mswin32-60) 4. win32-api 1.0.5 (ruby) 5. Skip this gem 6. Cancel installation The problem is this last step. Our users are confused by this question. The best answer is almost always #1 (this is a precompiled binary), and I would like specify this as the default in the Watir gemspec, but i don't know how. If users pick #2 (as many do), they will usually get errors (because it only works if they have a compiler installed: most watir users don't). And it becomes difficult for them to recover. Many end up uninstalling Ruby and starting over. So it ends up being a complete FAIL. I would like your advice as to whether there is anything i can do with the Watir gemspec to avoid this situation. Here is the watir gemspec. (Watir currently only works on Windows -- I'm working on that, but that is a separate issue.) https://svn.openqa.org/svn/watir/trunk/watir/watir.gemspec Here is my recent correspondence with Daniel Berger (author of win32-utils) on this issue. http://rubyforge.org/tracker/index.php?func=detail&aid=20499&group_id=85&atid=412 Appreciate any help or insight you can provide. Best regards, Bret -- Bret Pettichord CTO, WatirCraft LLC Lead Developer, Watir, http://wtr.rubyforge.org Blog (Essays), http://www.io.com/~wazmo/blog MiniBlog (Links), http://feeds.feedburner.com/bretshotlist From gthiesfeld at gmail.com Tue Jun 3 23:02:05 2008 From: gthiesfeld at gmail.com (Gordon Thiesfeld) Date: Tue, 3 Jun 2008 22:02:05 -0500 Subject: [Rubygems-developers] Help with Gem Dependencies In-Reply-To: References: Message-ID: On Tue, Jun 3, 2008 at 8:30 PM, Bret Pettichord wrote: > > Appreciate any help or insight you can provide. I'm more of a lurker than an authority on this list, but it appears you have an older version of rubygems installed. RubyGems prior to 1.0 or thereabouts would prompt the user for which version of the gem to install. Newer versions will do the right thing, and install the correct gem. To check this which version you have installed, you would run C:\ruby>gem -v 1.1.1 If it's older than 1.1.1, I would recommend updating. C:\ruby>gem update --system Updating RubyGems Hope that helps, Gordon From bret at pettichord.com Tue Jun 3 23:17:53 2008 From: bret at pettichord.com (Bret Pettichord) Date: Tue, 3 Jun 2008 22:17:53 -0500 Subject: [Rubygems-developers] Help with Gem Dependencies In-Reply-To: References: Message-ID: That's useful information >gem -v 0.9.2 Because of some bugs in Ruby 1.8.6, we are still using Ruby 1.8.5. Haven't looked at 1.8.7 yet. I'll look into your suggestion further... Bret On Tue, Jun 3, 2008 at 10:02 PM, Gordon Thiesfeld wrote: > On Tue, Jun 3, 2008 at 8:30 PM, Bret Pettichord wrote: >> >> Appreciate any help or insight you can provide. > > I'm more of a lurker than an authority on this list, but it appears > you have an older version of rubygems installed. RubyGems prior to > 1.0 or thereabouts would prompt the user for which version of the gem > to install. Newer versions will do the right thing, and install the > correct gem. > > To check this which version you have installed, you would run > > C:\ruby>gem -v > 1.1.1 > > If it's older than 1.1.1, I would recommend updating. > > C:\ruby>gem update --system > Updating RubyGems > > Hope that helps, > > Gordon > _______________________________________________ > Rubygems-developers mailing list > Rubygems-developers at rubyforge.org > http://rubyforge.org/mailman/listinfo/rubygems-developers > -- Bret Pettichord CTO, WatirCraft LLC Lead Developer, Watir, http://wtr.rubyforge.org Blog (Essays), http://www.io.com/~wazmo/blog MiniBlog (Links), http://feeds.feedburner.com/bretshotlist From bret at pettichord.com Tue Jun 3 23:34:06 2008 From: bret at pettichord.com (Bret Pettichord) Date: Tue, 3 Jun 2008 22:34:06 -0500 Subject: [Rubygems-developers] Help with Gem Dependencies In-Reply-To: References: Message-ID: I confirmed that your suggestion works as you describe. Thanks. However, what i want to do is make "gem install watir" work as a one-step install. With your suggestion it is now a 2-step install. ("gem update --system; gem install watir") I was hoping that i could just add a dependency on rubygems-update to the watir gem, but this in itself is not sufficient to fix the dependency problem -- i need the full gem update --system. Do you or others know if there is a way to add a dependency on this ("gem update --system') as part of the gem install for Watir (by changing its gemspec)? Another option would be for us to move to Ruby 1.8.7. which surely has other benefits as well. Bret On Tue, Jun 3, 2008 at 10:17 PM, Bret Pettichord wrote: > That's useful information > >>gem -v > 0.9.2 > > Because of some bugs in Ruby 1.8.6, we are still using Ruby 1.8.5. > Haven't looked at 1.8.7 yet. I'll look into your suggestion further... > > Bret > > > > On Tue, Jun 3, 2008 at 10:02 PM, Gordon Thiesfeld wrote: >> On Tue, Jun 3, 2008 at 8:30 PM, Bret Pettichord wrote: >>> >>> Appreciate any help or insight you can provide. >> >> I'm more of a lurker than an authority on this list, but it appears >> you have an older version of rubygems installed. RubyGems prior to >> 1.0 or thereabouts would prompt the user for which version of the gem >> to install. Newer versions will do the right thing, and install the >> correct gem. >> >> To check this which version you have installed, you would run >> >> C:\ruby>gem -v >> 1.1.1 >> >> If it's older than 1.1.1, I would recommend updating. >> >> C:\ruby>gem update --system >> Updating RubyGems >> >> Hope that helps, >> >> Gordon >> _______________________________________________ >> Rubygems-developers mailing list >> Rubygems-developers at rubyforge.org >> http://rubyforge.org/mailman/listinfo/rubygems-developers >> > > > > -- > Bret Pettichord > CTO, WatirCraft LLC > Lead Developer, Watir, http://wtr.rubyforge.org > Blog (Essays), http://www.io.com/~wazmo/blog > MiniBlog (Links), http://feeds.feedburner.com/bretshotlist > -- Bret Pettichord CTO, WatirCraft LLC Lead Developer, Watir, http://wtr.rubyforge.org Blog (Essays), http://www.io.com/~wazmo/blog MiniBlog (Links), http://feeds.feedburner.com/bretshotlist From gthiesfeld at gmail.com Wed Jun 4 00:29:40 2008 From: gthiesfeld at gmail.com (Gordon Thiesfeld) Date: Tue, 3 Jun 2008 23:29:40 -0500 Subject: [Rubygems-developers] Help with Gem Dependencies In-Reply-To: References: Message-ID: On Tue, Jun 3, 2008 at 10:34 PM, Bret Pettichord wrote: > I confirmed that your suggestion works as you describe. Thanks. > > However, what i want to do is make "gem install watir" work as a > one-step install. With your suggestion it is now a 2-step install. > ("gem update --system; gem install watir") It may seem like I'm quibbling over semantics here, but I think at distinction needs to be made. Installing watir in this way is not a 2 step install, but a one step install with an added requirement. Users are already required to run Windows, and to have ruby installed. This would just require they upgrade to a newer version of RubyGems. I agree this isn't the most optimal solution, but it's what is available right now. When the next version of the One Click installer ships, it will ship with the latest production version of RubyGems, and you'll be back to the 2 original requirements. > > Another option would be for us to move to Ruby 1.8.7. which surely has > other benefits as well. I would recommend against that at this point. From what I've read, Ruby 1.8.7 is not completely backward compatible, and code will break. Also, I'd be interested to hear what sort of bugs you're encountering in 1.8.6. Send an email to the rubyinstaller (One Click Installer project for Windows) mailing list. http://rubyforge.org/mail/?group_id=167 Thanks, Gordon From thewoolleyman at gmail.com Wed Jun 4 02:30:51 2008 From: thewoolleyman at gmail.com (Chad Woolley) Date: Tue, 3 Jun 2008 23:30:51 -0700 Subject: [Rubygems-developers] Problems with trunk (rev 1708) - server source index refresh losing config-file overrides Message-ID: Hi, I already talked with Eric about this off-list. I just reproduced it again so I'm reporting it. In rev 1708, a change was added to refresh the source index every time through so new gems get picked up This causes problems when I start my server with a --config-file override, pointing gemhome and gempath to a custom location containing a test gem repo with some test gems. The issue is when I run "gem list --remote" against this server, it lists all the gems in my system location as well as the test gems. Prior to the change in 1708 it would only list the gems in the dir that I specified in the config-file (the correct behavior, I believe). Not sure how to fix this and still retain the original bugfix. I opened a bug here: http://rubyforge.org/tracker/index.php?func=detail&aid=20509&group_id=126&atid=575 Thanks, -- Chad From stephen.bannasch at deanbrook.org Wed Jun 4 03:33:21 2008 From: stephen.bannasch at deanbrook.org (Stephen Bannasch) Date: Wed, 4 Jun 2008 03:33:21 -0400 Subject: [Rubygems-developers] HEADSUP RubyGems 1.2 Real Soon Now In-Reply-To: <69a2885c0806031822v3baed80bv78e30d60fb8310b7@mail.gmail.com> References: <69a2885c0806031822v3baed80bv78e30d60fb8310b7@mail.gmail.com> Message-ID: At 6:22 PM -0700 6/3/08, Jeremy Kemper wrote: >On Tue, Jun 3, 2008 at 4:36 PM, Eric Hodel wrote: >> I believe RubyGems is currently feature-complete for the next release. For >> the next while I'll be focusing on bugfixes and patches from the tracker. I >> expect to release a new version in two weeks at minimum, possibly longer. > >I'd love to see little-known --format-executable enabled by default >for gem installs. > >This gives you bin stubs that match your ruby name, e.g. rake-1.9 for >ruby-1.9 and rake for ruby. Currently, both are installed as rake so >the latest install clobbers the previous one. This is confusing and >aggravating but few are aware that --format-executable solves it. > >Changing the default would be a welcome improvement in gem install >experience for those working with multiple rubies and doesn't change >behavior for the 95% who aren't. Plus, the 1.2 release is an >auspicious opportunity to flip the switch just as 1.8.7 is out and >1.9.1 nears release. I would like the opposite to be the default. I keep all my different ruby installations separate -- I have different lib, bin, and gem repo paths for 1.8.6, 1.9. rbx, and jruby. I don't see how a single gem repository can work when gems that require native code and connections to ruby VM libraries are combined. -- background on my setup -- I don't want different names for the same command -- but I do want an simple way to run a bin/ command from any of the installed ruby vms. Using the -S parameter works for MRI 1.8.6 and jruby, partially in ruby 1.9 (works for gem and not for rake) but not for rubinius: This is my default Ruby install. It's the MRI 1.8.6 that comes with MacOS 10.5.2. This is the only Ruby VM that uses ruby scripts stored in a standard system bin/ dir. [~/dev/rails/test]$ gem env RubyGems Environment: - RUBYGEMS VERSION: 1.1.1 - RUBY VERSION: 1.8.6 (2007-09-24 patchlevel 111) [universal-darwin9.0] - INSTALLATION DIRECTORY: /Library/Ruby/Gems/1.8 - RUBY EXECUTABLE: /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/ruby - RUBYGEMS PLATFORMS: - ruby - universal-darwin-9 - GEM PATHS: - /Library/Ruby/Gems/1.8 - /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/gems/1.8 - GEM CONFIGURATION: - :update_sources => true - :verbose => true - :benchmark => false - :backtrace => false - :bulk_threshold => 1000 - :sources => ["http://gems.rubyforge.org"] - REMOTE SOURCES: - http://gems.rubyforge.org Paths to jruby and ruby 1.9 bin/ directories are added to the end of PATH and I renamed the ruby shell script in ruby 1.9's bin/ dir to ruby19. [~/dev/rails/test]$ jruby -S gem env RubyGems Environment: - RUBYGEMS VERSION: 1.1.1 - RUBY VERSION: 1.8.6 (2008-06-01 patchlevel 6586) [java] - INSTALLATION DIRECTORY: /Users/stephen/dev/jruby_trunk/jruby/lib/ruby/gems/1.8 - RUBY EXECUTABLE: /Users/stephen/dev/jruby_trunk/jruby/bin/jruby - RUBYGEMS PLATFORMS: - ruby - universal-java-1.5 - GEM PATHS: - /Users/stephen/dev/jruby_trunk/jruby/lib/ruby/gems/1.8 - GEM CONFIGURATION: - :update_sources => true - :verbose => true - :benchmark => false - :backtrace => false - :bulk_threshold => 1000 - :sources => ["http://gems.rubyforge.org"] - REMOTE SOURCES: - http://gems.rubyforge.org [~/dev/rails/test]$ ruby19 -S gem env RubyGems Environment: - RUBYGEMS VERSION: 1.1.1 - RUBY VERSION: 1.9.0 (2008-05-19 patchlevel 0) [i686-darwin9.2.2] - INSTALLATION DIRECTORY: /Users/stephen/dev/ruby1.9/lib/ruby/gems/1.9.0 - RUBY EXECUTABLE: /Users/stephen/dev/ruby1.9/bin/ruby - RUBYGEMS PLATFORMS: - ruby - x86-darwin-9 - GEM PATHS: - /Users/stephen/dev/ruby1.9/lib/ruby/gems/1.9.0 - GEM CONFIGURATION: - :update_sources => true - :verbose => true - :benchmark => false - :backtrace => false - :bulk_threshold => 1000 - :sources => ["http://gems.rubyforge.org"] - REMOTE SOURCES: - http://gems.rubyforge.org I installed rubinius source into rubinius/code and installed it into rubinius/install. cd ~/dev/rubinius git clone git://github.com/evanphx/rubinius.git code cd ~/dev/rubinius/code rake clean:all PREFIX=/Users/stephen/dev/rubinius/install rake build PREFIX=/Users/stephen/dev/rubinius/install rake install But since Rubinius doesn't have the equivalent of '-S' I need to supply the full path to the gem.rb command. [~/dev/rubinius/install]$ rbx lib/rubinius/0.8/bin/gem.rb env RubyGems Environment: - RUBYGEMS VERSION: 1.1.1 - RUBY VERSION: 1.8.6 (06/04/2008 patchlevel 111) [i686-apple-darwin9.2.2] - INSTALLATION DIRECTORY: /Users/stephen/dev/rubinius/install/lib/rubinius/lib/rbx/gems/1.8.6 - RUBY EXECUTABLE: /Users/stephen/dev/rubinius/install/lib/rubinius/bin/rbx - RUBYGEMS PLATFORMS: - ruby - x86-darwin-9 - GEM PATHS: - /Users/stephen/dev/rubinius/install/lib/rubinius/lib/rbx/gems/1.8.6 - GEM CONFIGURATION: - :update_sources => true - :verbose => true - :benchmark => false - :backtrace => false - :bulk_threshold => 1000 - :sources => ["http://gems.rubyforge.org"] - REMOTE SOURCES: - http://gems.rubyforge.org From drbrain at segment7.net Wed Jun 4 05:38:36 2008 From: drbrain at segment7.net (Eric Hodel) Date: Wed, 4 Jun 2008 02:38:36 -0700 Subject: [Rubygems-developers] Help with Gem Dependencies In-Reply-To: References: Message-ID: <11CF3DEB-9C3D-40B4-AE73-8664B4CC2C68@segment7.net> On Jun 3, 2008, at 20:17 PM, Bret Pettichord wrote: > That's useful information > >> gem -v > 0.9.2 > > Because of some bugs in Ruby 1.8.6, we are still using Ruby 1.8.5. > Haven't looked at 1.8.7 yet. I'll look into your suggestion further... All versions of RubyGems newer (and probably all older) than 0.9.2 work on Ruby 1.8.4 and newer. You do not need to update ruby to use an updated RubyGems. From drbrain at segment7.net Wed Jun 4 06:05:37 2008 From: drbrain at segment7.net (Eric Hodel) Date: Wed, 4 Jun 2008 03:05:37 -0700 Subject: [Rubygems-developers] Help with Gem Dependencies In-Reply-To: References: Message-ID: Please don't top post. On Jun 3, 2008, at 20:34 PM, Bret Pettichord wrote: > I confirmed that your suggestion works as you describe. Thanks. > > However, what i want to do is make "gem install watir" work as a > one-step install. With your suggestion it is now a 2-step install. > ("gem update --system; gem install watir") A quick analysis of the gem repository access log shows only 20% of the hits from RubyGems having a version of 0.9.4 or older. For most of your users there is likely no need to update RubyGems. > I was hoping that i could just add a dependency on rubygems-update to > the watir gem, but this in itself is not sufficient to fix the > dependency problem -- i need the full gem update --system. I believe you need at least RubyGems 0.9.5 to depend on a particular version of RubyGems, but this will not force an update of RubyGems itself. > Do you or others know if there is a way to add a dependency on this > ("gem update --system') as part of the gem install for Watir (by > changing its gemspec)? There is not. User interaction is required to update RubyGems, as a packaged RubyGems may have incompatible changes with standard RubyGems. > Another option would be for us to move to Ruby 1.8.7. which surely has > other benefits as well. Upgrading to Ruby 1.8.7 will not change the RubyGems version you are using. From drbrain at segment7.net Wed Jun 4 06:15:56 2008 From: drbrain at segment7.net (Eric Hodel) Date: Wed, 4 Jun 2008 03:15:56 -0700 Subject: [Rubygems-developers] HEADSUP RubyGems 1.2 Real Soon Now In-Reply-To: References: <69a2885c0806031822v3baed80bv78e30d60fb8310b7@mail.gmail.com> Message-ID: On Jun 4, 2008, at 00:33 AM, Stephen Bannasch wrote: > At 6:22 PM -0700 6/3/08, Jeremy Kemper wrote: >> On Tue, Jun 3, 2008 at 4:36 PM, Eric Hodel >> wrote: >>> I believe RubyGems is currently feature-complete for the next >>> release. For >>> the next while I'll be focusing on bugfixes and patches from the >>> tracker. I >>> expect to release a new version in two weeks at minimum, possibly >>> longer. >> >> I'd love to see little-known --format-executable enabled by default >> for gem installs. > > I would like the opposite to be the default. I would love to make --format-executable the default, but that will cause too much confusion and will inconvenience the majority too much. (Maybe I shouldn't have made it default for setup.rb/gem update --system, but the two new rubygems/defaults files may help improve that situation.) > -- background on my setup -- [...] > I installed rubinius source into rubinius/code and installed it into > rubinius/install. > > But since Rubinius doesn't have the equivalent of '-S' I need to > supply the full path to the gem.rb command. `rbx gem env` will do what you want. We have discussed making gem executables accessible via rbx as a subcommand, `rbx rake`. We will probably wire this in via the rubygems/defaults file. From jeremy at bitsweat.net Wed Jun 4 12:59:18 2008 From: jeremy at bitsweat.net (Jeremy Kemper) Date: Wed, 4 Jun 2008 09:59:18 -0700 Subject: [Rubygems-developers] HEADSUP RubyGems 1.2 Real Soon Now In-Reply-To: References: <69a2885c0806031822v3baed80bv78e30d60fb8310b7@mail.gmail.com> Message-ID: <69a2885c0806040959v2f84f4bbgdf5297c9dc15b134@mail.gmail.com> On Wed, Jun 4, 2008 at 12:33 AM, Stephen Bannasch wrote: > At 6:22 PM -0700 6/3/08, Jeremy Kemper wrote: >>On Tue, Jun 3, 2008 at 4:36 PM, Eric Hodel wrote: >>> I believe RubyGems is currently feature-complete for the next release. For >>> the next while I'll be focusing on bugfixes and patches from the tracker. I >>> expect to release a new version in two weeks at minimum, possibly longer. >> >>I'd love to see little-known --format-executable enabled by default >>for gem installs. >> >>This gives you bin stubs that match your ruby name, e.g. rake-1.9 for >>ruby-1.9 and rake for ruby. Currently, both are installed as rake so >>the latest install clobbers the previous one. This is confusing and >>aggravating but few are aware that --format-executable solves it. >> >>Changing the default would be a welcome improvement in gem install >>experience for those working with multiple rubies and doesn't change >>behavior for the 95% who aren't. Plus, the 1.2 release is an >>auspicious opportunity to flip the switch just as 1.8.7 is out and >>1.9.1 nears release. > > I would like the opposite to be the default. > > I keep all my different ruby installations separate -- I have different lib, bin, and gem repo paths for 1.8.6, 1.9. rbx, and jruby. I don't see how a single gem repository can work when gems that require native code and connections to ruby VM libraries are combined. Unless I'm missing something, your setup is unaffected by this option because you don't use the program prefix or suffix. jeremy From jeremy at bitsweat.net Wed Jun 4 13:03:34 2008 From: jeremy at bitsweat.net (Jeremy Kemper) Date: Wed, 4 Jun 2008 10:03:34 -0700 Subject: [Rubygems-developers] HEADSUP RubyGems 1.2 Real Soon Now In-Reply-To: References: <69a2885c0806031822v3baed80bv78e30d60fb8310b7@mail.gmail.com> Message-ID: <69a2885c0806041003w50b188ddl5bba2d52a3894b1f@mail.gmail.com> On Wed, Jun 4, 2008 at 3:15 AM, Eric Hodel wrote: > > On Jun 4, 2008, at 00:33 AM, Stephen Bannasch wrote: > >> At 6:22 PM -0700 6/3/08, Jeremy Kemper wrote: >>> >>> On Tue, Jun 3, 2008 at 4:36 PM, Eric Hodel wrote: >>>> >>>> I believe RubyGems is currently feature-complete for the next release. >>>> For >>>> the next while I'll be focusing on bugfixes and patches from the >>>> tracker. I >>>> expect to release a new version in two weeks at minimum, possibly >>>> longer. >>> >>> I'd love to see little-known --format-executable enabled by default >>> for gem installs. >> >> I would like the opposite to be the default. > > I would love to make --format-executable the default, but that will cause > too much confusion and will inconvenience the majority too much. (Maybe I > shouldn't have made it default for setup.rb/gem update --system, but the two > new rubygems/defaults files may help improve that situation.) The naming changes only when that person has changed his ruby's naming also, so it feels natural. The majority have a vanilla ruby so they'll see no change or confusion. > >> -- background on my setup -- > > [...] > >> I installed rubinius source into rubinius/code and installed it into >> rubinius/install. >> >> But since Rubinius doesn't have the equivalent of '-S' I need to supply >> the full path to the gem.rb command. > > `rbx gem env` will do what you want. > > We have discussed making gem executables accessible via rbx as a subcommand, > `rbx rake`. We will probably wire this in via the rubygems/defaults file. jeremy From jftucker at gmail.com Wed Jun 4 13:41:10 2008 From: jftucker at gmail.com (James Tucker) Date: Wed, 4 Jun 2008 18:41:10 +0100 Subject: [Rubygems-developers] HEADSUP RubyGems 1.2 Real Soon Now In-Reply-To: <69a2885c0806041003w50b188ddl5bba2d52a3894b1f@mail.gmail.com> References: <69a2885c0806031822v3baed80bv78e30d60fb8310b7@mail.gmail.com> <69a2885c0806041003w50b188ddl5bba2d52a3894b1f@mail.gmail.com> Message-ID: On 4 Jun 2008, at 18:03, Jeremy Kemper wrote: > On Wed, Jun 4, 2008 at 3:15 AM, Eric Hodel > wrote: >> >> On Jun 4, 2008, at 00:33 AM, Stephen Bannasch wrote: >> >>> At 6:22 PM -0700 6/3/08, Jeremy Kemper wrote: >>>> >>>> On Tue, Jun 3, 2008 at 4:36 PM, Eric Hodel >>>> wrote: >>>>> >>>>> I believe RubyGems is currently feature-complete for the next >>>>> release. >>>>> For >>>>> the next while I'll be focusing on bugfixes and patches from the >>>>> tracker. I >>>>> expect to release a new version in two weeks at minimum, possibly >>>>> longer. >>>> >>>> I'd love to see little-known --format-executable enabled by default >>>> for gem installs. >>> >>> I would like the opposite to be the default. >> >> I would love to make --format-executable the default, but that will >> cause >> too much confusion and will inconvenience the majority too much. >> (Maybe I >> shouldn't have made it default for setup.rb/gem update --system, >> but the two >> new rubygems/defaults files may help improve that situation.) > > The naming changes only when that person has changed his ruby's naming > also, so it feels natural. > > The majority have a vanilla ruby so they'll see no change or > confusion. The problem is expectation. People run `ruby foo.rb` and it works, so they expect `gem ...` to work too. Distros pack in a link which is what fools people into thinking they're getting it without the suffix. My solution to this problem is also to keep implementations seperate, and in that regard, continually having to add extensions to the commands i use daily, and really mostly messing with tab completion speed, is a must not. As it is, on most of our platforms I re-link gem to gem1(\.)?8 as appropriate. I then switch between 'contents' with a bash function: http://pastie.textmate.org/208786 > > > >> >>> -- background on my setup -- >> >> [...] >> >>> I installed rubinius source into rubinius/code and installed it into >>> rubinius/install. >>> >>> But since Rubinius doesn't have the equivalent of '-S' I need to >>> supply >>> the full path to the gem.rb command. >> >> `rbx gem env` will do what you want. >> >> We have discussed making gem executables accessible via rbx as a >> subcommand, >> `rbx rake`. We will probably wire this in via the rubygems/ >> defaults file. > > > jeremy > _______________________________________________ > Rubygems-developers mailing list > Rubygems-developers at rubyforge.org > http://rubyforge.org/mailman/listinfo/rubygems-developers From vsizikov at gmail.com Wed Jun 4 13:54:19 2008 From: vsizikov at gmail.com (Vladimir Sizikov) Date: Wed, 4 Jun 2008 19:54:19 +0200 Subject: [Rubygems-developers] HEADSUP RubyGems 1.2 Real Soon Now In-Reply-To: References: <69a2885c0806031822v3baed80bv78e30d60fb8310b7@mail.gmail.com> <69a2885c0806041003w50b188ddl5bba2d52a3894b1f@mail.gmail.com> Message-ID: <3454c9680806041054pf971a78i65a417150314794@mail.gmail.com> Hi James, On Wed, Jun 4, 2008 at 7:41 PM, James Tucker wrote: >> The naming changes only when that person has changed his ruby's naming >> also, so it feels natural. >> >> The majority have a vanilla ruby so they'll see no change or confusion. > > > The problem is expectation. People run `ruby foo.rb` and it works, so they > expect `gem ...` to work too. Distros pack in a link which is what fools > people into thinking they're getting it without the suffix. Indeed, not to mention the alternative implementations (that are seem to be multiplying: JRuby, Rubinius, IronRuby, etc, etc). And, as usual, different users expect different things with naming. In JRuby lang, it seems, the common consensus is to stick with standard names though. > My solution to this problem is also to keep implementations seperate, and in > that regard, continually having to add extensions to the commands i use > daily, and really mostly messing with tab completion speed, is a must not. > As it is, on most of our platforms I re-link gem to gem1(\.)?8 as > appropriate. JRuby's standard solution is to use -S switch: jruby -S gem, jruby -S rake, jruby -S spec, etc. That way, you can *guarantee* that the proper JRuby version is used (the one you specified explicitly, of from the PATH). Thanks, --Vladimir From drbrain at segment7.net Wed Jun 4 14:23:47 2008 From: drbrain at segment7.net (Eric Hodel) Date: Wed, 4 Jun 2008 11:23:47 -0700 Subject: [Rubygems-developers] HEADSUP RubyGems 1.2 Real Soon Now In-Reply-To: <69a2885c0806041003w50b188ddl5bba2d52a3894b1f@mail.gmail.com> References: <69a2885c0806031822v3baed80bv78e30d60fb8310b7@mail.gmail.com> <69a2885c0806041003w50b188ddl5bba2d52a3894b1f@mail.gmail.com> Message-ID: <81C8D58A-50DE-40F8-9330-E36A86C0747A@segment7.net> On Jun 4, 2008, at 10:03 AM, Jeremy Kemper wrote: > On Wed, Jun 4, 2008 at 3:15 AM, Eric Hodel > wrote: >> On Jun 4, 2008, at 00:33 AM, Stephen Bannasch wrote: >>> At 6:22 PM -0700 6/3/08, Jeremy Kemper wrote: >>>> On Tue, Jun 3, 2008 at 4:36 PM, Eric Hodel >>>> wrote: >>>>> >>>>> I believe RubyGems is currently feature-complete for the next >>>>> release. >>>>> For >>>>> the next while I'll be focusing on bugfixes and patches from the >>>>> tracker. I >>>>> expect to release a new version in two weeks at minimum, possibly >>>>> longer. >>>> >>>> I'd love to see little-known --format-executable enabled by default >>>> for gem installs. >>> >>> I would like the opposite to be the default. >> >> I would love to make --format-executable the default, but that will >> cause >> too much confusion and will inconvenience the majority too much. >> (Maybe I >> shouldn't have made it default for setup.rb/gem update --system, >> but the two >> new rubygems/defaults files may help improve that situation.) > > The naming changes only when that person has changed his ruby's naming > also, so it feels natural. > > The majority have a vanilla ruby so they'll see no change or > confusion. apt-packaged ruby installs as ruby1.8, FreeBSD ports ruby installs as ruby18, and both provide a link from ruby to the correct name. From the setup.rb change, I believe a majority of the other packaging systems install ruby this way. Not as many people build ruby by hand. If you want to make --format-executable the default for you, ~/.gemrc allows you to make it so. From jeremy at bitsweat.net Wed Jun 4 14:42:12 2008 From: jeremy at bitsweat.net (Jeremy Kemper) Date: Wed, 4 Jun 2008 11:42:12 -0700 Subject: [Rubygems-developers] HEADSUP RubyGems 1.2 Real Soon Now In-Reply-To: <81C8D58A-50DE-40F8-9330-E36A86C0747A@segment7.net> References: <69a2885c0806031822v3baed80bv78e30d60fb8310b7@mail.gmail.com> <69a2885c0806041003w50b188ddl5bba2d52a3894b1f@mail.gmail.com> <81C8D58A-50DE-40F8-9330-E36A86C0747A@segment7.net> Message-ID: <69a2885c0806041142ob56e913i20117bd7355c3532@mail.gmail.com> On Wed, Jun 4, 2008 at 11:23 AM, Eric Hodel wrote: > On Jun 4, 2008, at 10:03 AM, Jeremy Kemper wrote: >> >> On Wed, Jun 4, 2008 at 3:15 AM, Eric Hodel wrote: >>> >>> On Jun 4, 2008, at 00:33 AM, Stephen Bannasch wrote: >>>> >>>> At 6:22 PM -0700 6/3/08, Jeremy Kemper wrote: >>>>> >>>>> On Tue, Jun 3, 2008 at 4:36 PM, Eric Hodel >>>>> wrote: >>>>>> >>>>>> I believe RubyGems is currently feature-complete for the next release. >>>>>> For >>>>>> the next while I'll be focusing on bugfixes and patches from the >>>>>> tracker. I >>>>>> expect to release a new version in two weeks at minimum, possibly >>>>>> longer. >>>>> >>>>> I'd love to see little-known --format-executable enabled by default >>>>> for gem installs. >>>> >>>> I would like the opposite to be the default. >>> >>> I would love to make --format-executable the default, but that will cause >>> too much confusion and will inconvenience the majority too much. (Maybe >>> I >>> shouldn't have made it default for setup.rb/gem update --system, but the >>> two >>> new rubygems/defaults files may help improve that situation.) >> >> The naming changes only when that person has changed his ruby's naming >> also, so it feels natural. >> >> The majority have a vanilla ruby so they'll see no change or confusion. > > apt-packaged ruby installs as ruby1.8, FreeBSD ports ruby installs as > ruby18, and both provide a link from ruby to the correct name. From the > setup.rb change, I believe a majority of the other packaging systems install > ruby this way. Not as many people build ruby by hand. Hm, that's true. Bummer. > If you want to make --format-executable the default for you, ~/.gemrc allows > you to make it so. Yep. I'll stick with that. Thanks, jeremy From ryand-ruby at zenspider.com Wed Jun 4 15:19:07 2008 From: ryand-ruby at zenspider.com (Ryan Davis) Date: Wed, 4 Jun 2008 12:19:07 -0700 Subject: [Rubygems-developers] HEADSUP RubyGems 1.2 Real Soon Now In-Reply-To: <200806032117.21230.avatar@spellboundnet.com> References: <2bce3eb60806031728g7e9ef38amf688ae8411a2b3c8@mail.gmail.com> <200806032117.21230.avatar@spellboundnet.com> Message-ID: <3E5F352E-9AB3-40C6-A9F7-3A630B9B3445@zenspider.com> On Jun 3, 2008, at 18:17 , Donavan Pantke wrote: > The :install flag is required for gems that have specific loading > requirements, and so cannot have dependencies automatically > activated. The > biggest use case is Passenger, which can activate multiple versions > of Rails. > It originally required rails in the gemspec (as it needs some > version of > Rails), but that meant that when the passenger gem activated, rails > automatically activated as well. That caused passenger to blow up > when trying > to activate a different version of Rails. Having the :install flag > will allow > Passenger to be loaded but let Passenger worry about Rails. Biggest use-case, or only use-case? I suspect it is the latter and as such think that adding it is more confusing than leaving it out. It is incredibly hard to explain (this thread is evidence) and I can easily imagine it being misused more than it helps. Passenger is very very edge-case to most ruby projects out there. Eric is doing a damn good job of stripping out a ton of cruft from rubygems and making things a lot more clear, both internally and for users. I'd like to see some real need for a feature before it goes into rubygems. From stephen.bannasch at deanbrook.org Wed Jun 4 15:46:16 2008 From: stephen.bannasch at deanbrook.org (Stephen Bannasch) Date: Wed, 4 Jun 2008 15:46:16 -0400 Subject: [Rubygems-developers] HEADSUP RubyGems 1.2 Real Soon Now In-Reply-To: References: <69a2885c0806031822v3baed80bv78e30d60fb8310b7@mail.gmail.com> Message-ID: At 3:15 AM -0700 6/4/08, Eric Hodel wrote: >>I installed rubinius source into rubinius/code and installed it into rubinius/install. >> >>But since Rubinius doesn't have the equivalent of '-S' I need to supply the full path to the gem.rb command. > >`rbx gem env` will do what you want. Thanks for that pointer -- it works just as it should! And in my non-system install of rubinius located here: ~/dev/rubinius/install doing this: $ rbx gem install uuidtools Indeed puts the uuidtools gem here: ./lib/rubinius/lib/rbx/gems/1.8.6/gems/uuidtools-1.0.3 This may be more appropriate for a rubinius list but then running: $ rbx gem list --local produces this error: *** LOCAL GEMS *** ERROR: While executing gem ... (NoMethodError) No method 'to_ints' on an instance of NilClass. >We have discussed making gem executables accessible via rbx as a subcommand, `rbx rake`. We will probably wire this in via the rubygems/defaults file. I'll look forward to that. Thanks. From thewoolleyman at gmail.com Wed Jun 4 16:31:07 2008 From: thewoolleyman at gmail.com (Chad Woolley) Date: Wed, 4 Jun 2008 13:31:07 -0700 Subject: [Rubygems-developers] HEADSUP RubyGems 1.2 Real Soon Now In-Reply-To: <3E5F352E-9AB3-40C6-A9F7-3A630B9B3445@zenspider.com> References: <2bce3eb60806031728g7e9ef38amf688ae8411a2b3c8@mail.gmail.com> <200806032117.21230.avatar@spellboundnet.com> <3E5F352E-9AB3-40C6-A9F7-3A630B9B3445@zenspider.com> Message-ID: On Wed, Jun 4, 2008 at 12:19 PM, Ryan Davis wrote: > Biggest use-case, or only use-case? I suspect it is the latter and as such > think that adding it is more confusing than leaving it out. It is incredibly > hard to explain (this thread is evidence) and I can easily imagine it being > misused more than it helps. Agreed. Are there any other use cases? Plus, I already mentioned a workaround in an earlier thread - just have Passenger ensure correct gem installation at application runtime. Use GemInstaller, or do it manually (steal simpler config.gems/rake gem installation code from Rails). This is a bit more painful with edge cases (e.g. handling root-owned gem repos), but these are addressable (see my buglist for GemInstaller). In any case, not worth special handling in the gem spec spec, IMO -- Chad From drbrain at segment7.net Wed Jun 4 21:34:03 2008 From: drbrain at segment7.net (Eric Hodel) Date: Wed, 4 Jun 2008 18:34:03 -0700 Subject: [Rubygems-developers] HEADSUP RubyGems 1.2 Real Soon Now In-Reply-To: References: <69a2885c0806031822v3baed80bv78e30d60fb8310b7@mail.gmail.com> Message-ID: <50467331-9489-4E97-9485-DFAB4EE25334@segment7.net> On Jun 4, 2008, at 12:46 PM, Stephen Bannasch wrote: > At 3:15 AM -0700 6/4/08, Eric Hodel wrote: >>> I installed rubinius source into rubinius/code and installed it >>> into rubinius/install. >>> >>> But since Rubinius doesn't have the equivalent of '-S' I need to >>> supply the full path to the gem.rb command. >> >> `rbx gem env` will do what you want. > > Thanks for that pointer -- it works just as it should! > > And in my non-system install of rubinius located here: > > ~/dev/rubinius/install > > doing this: > > $ rbx gem install uuidtools > > Indeed puts the uuidtools gem here: > > ./lib/rubinius/lib/rbx/gems/1.8.6/gems/uuidtools-1.0.3 > > This may be more appropriate for a rubinius list but then running: > > $ rbx gem list --local > > produces this error: > > *** LOCAL GEMS *** > > ERROR: While executing gem ... (NoMethodError) > No method 'to_ints' on an instance of NilClass. A bunch of work has gone into completing rbconfig.rb (which may have caused such a problem) in the past day or two, so maybe this was fixed. From thewoolleyman at gmail.com Fri Jun 6 00:40:05 2008 From: thewoolleyman at gmail.com (Chad Woolley) Date: Thu, 5 Jun 2008 21:40:05 -0700 Subject: [Rubygems-developers] Problems with trunk (rev 1708) - server source index refresh losing config-file overrides In-Reply-To: References: Message-ID: On Tue, Jun 3, 2008 at 11:30 PM, Chad Woolley wrote: > opened a bug here: > http://rubyforge.org/tracker/index.php?func=detail&aid=20509&group_id=126&atid=575 Update on this. config-file seems to be a red herring. Real problem is that the trunk "gem list --remote" is reporting local system gems that are not in the servers dir, when the list command is run the *second* time. See details with commands to reproduce on the ticket. Anyone else seeing this? Thanks, -- Chad From sakaia at jp.fujitsu.com Fri Jun 6 05:13:02 2008 From: sakaia at jp.fujitsu.com (Atsushi SAKAI) Date: Fri, 06 Jun 2008 18:13:02 +0900 Subject: [Rubygems-developers] How to install rubygems on MinGW? Message-ID: <200806060913.m569D4OU021980@fjmscan502.ms.jp.fujitsu.com> Hi, I have a question about rubygems to install MinGW. If this mailing list is wrong for this issue, Please suggest me. I am trying to do ruby setup.py, but it generates many error message like follows. If any good page exists, please suggest me. ================= install -c -m 0755 C:/DOCUME~1/ADMINI~1/LOCALS~1/Temp/gem.bat C:/msys/1.0/local/bin/gem.bat rm C:/DOCUME~1/ADMINI~1/LOCALS~1/Temp/gem.bat rm -f C:/msys/1.0/local/lib/ruby/gems/1.8/source_cache rm -rf C:/msys/1.0/local/lib/ruby/gems/1.8/doc/rubygems-1.1.1 lib/rubygems/command_manager.rb:139:61: Skipping require of dynamic string: "rubygems/commands/#{command_name}_command" lib/rubygems/dependency_installer.rb:38:5: Unrecognized directive 'env_shebang' lib/rubygems/installer.rb:59:5: Unrecognized directive 'env_shebang' lib/rubygems/install_update_options.rb:22:32: ':' not followed by identified or operator lib/rubygems/install_update_options.rb:28:32: ':' not followed by identified or operator ================== Thanks Atsushi SAKAI From luislavena at gmail.com Fri Jun 6 05:38:25 2008 From: luislavena at gmail.com (Luis Lavena) Date: Fri, 6 Jun 2008 06:38:25 -0300 Subject: [Rubygems-developers] How to install rubygems on MinGW? In-Reply-To: <200806060913.m569D4OU021980@fjmscan502.ms.jp.fujitsu.com> References: <200806060913.m569D4OU021980@fjmscan502.ms.jp.fujitsu.com> Message-ID: <71166b3b0806060238q728b7440w797516fb65889641@mail.gmail.com> On Fri, Jun 6, 2008 at 6:13 AM, Atsushi SAKAI wrote: > Hi, > > I have a question about rubygems to install MinGW. > > If this mailing list is wrong for this issue, > Please suggest me. > > I am trying to do ruby setup.py, > but it generates many error message like follows. > If any good page exists, please suggest me. > > ================= > install -c -m 0755 C:/DOCUME~1/ADMINI~1/LOCALS~1/Temp/gem.bat C:/msys/1.0/local/bin/gem.bat > rm C:/DOCUME~1/ADMINI~1/LOCALS~1/Temp/gem.bat > rm -f C:/msys/1.0/local/lib/ruby/gems/1.8/source_cache > rm -rf C:/msys/1.0/local/lib/ruby/gems/1.8/doc/rubygems-1.1.1 > > lib/rubygems/command_manager.rb:139:61: Skipping require of dynamic string: "rubygems/commands/#{command_name}_command" > > lib/rubygems/dependency_installer.rb:38:5: Unrecognized directive 'env_shebang' > > lib/rubygems/installer.rb:59:5: Unrecognized directive 'env_shebang' > > lib/rubygems/install_update_options.rb:22:32: ':' not followed by identified or operator > > lib/rubygems/install_update_options.rb:28:32: ':' not followed by identified or operator > ================== > > Thanks > Atsushi SAKAI > Hello Atsushi, Are you trying to install rubygems running MSYS console or what? I fully don't understand your question, but it seems is related to how path is being split. Can you provide more information about the ruby version, the MinGW and the console (MSYS or plain cmd.exe), Windows version and version of MinGW stuff you're trying to get it installed into? Regards, -- Luis Lavena AREA 17 - Human beings, who are almost unique in having the ability to learn from the experience of others, are also remarkable for their apparent disinclination to do so. Douglas Adams From sakaia at jp.fujitsu.com Fri Jun 6 07:05:06 2008 From: sakaia at jp.fujitsu.com (Atsushi SAKAI) Date: Fri, 06 Jun 2008 20:05:06 +0900 Subject: [Rubygems-developers] How to install rubygems on MinGW? In-Reply-To: <71166b3b0806060238q728b7440w797516fb65889641@mail.gmail.com> References: <71166b3b0806060238q728b7440w797516fb65889641@mail.gmail.com> Message-ID: <200806061105.m56B57pM021781@fjmscan502.ms.jp.fujitsu.com> Hi, Luis Thank your for quick response. I am trying to install rubygems running MSYS console (rxvt). Ruby version is ruby 1.8.4 (2005-12-24) [i386-minw32] Now I am using Windows XP. and MinGW is (from gcc) gcc.exe (GCC) 3.4.5 (mingw special) I do someting wrong? > Are you trying to install rubygems running MSYS console or what? I > fully don't understand your question, but it seems is related to how > path is being split. > > Can you provide more information about the ruby version, the MinGW and > the console (MSYS or plain cmd.exe), Windows version and version of > MinGW stuff you're trying to get it installed into? > Thanks Atsushi SAKAI "Luis Lavena" wrote: > On Fri, Jun 6, 2008 at 6:13 AM, Atsushi SAKAI wrote: > > Hi, > > > > I have a question about rubygems to install MinGW. > > > > If this mailing list is wrong for this issue, > > Please suggest me. > > > > I am trying to do ruby setup.py, > > but it generates many error message like follows. > > If any good page exists, please suggest me. > > > > ================= > > install -c -m 0755 C:/DOCUME~1/ADMINI~1/LOCALS~1/Temp/gem.bat C:/msys/1.0/local/bin/gem.bat > > rm C:/DOCUME~1/ADMINI~1/LOCALS~1/Temp/gem.bat > > rm -f C:/msys/1.0/local/lib/ruby/gems/1.8/source_cache > > rm -rf C:/msys/1.0/local/lib/ruby/gems/1.8/doc/rubygems-1.1.1 > > > > lib/rubygems/command_manager.rb:139:61: Skipping require of dynamic string: "rubygems/commands/#{command_name}_command" > > > > lib/rubygems/dependency_installer.rb:38:5: Unrecognized directive 'env_shebang' > > > > lib/rubygems/installer.rb:59:5: Unrecognized directive 'env_shebang' > > > > lib/rubygems/install_update_options.rb:22:32: ':' not followed by identified or operator > > > > lib/rubygems/install_update_options.rb:28:32: ':' not followed by identified or operator > > ================== > > > > Thanks > > Atsushi SAKAI > > > > Hello Atsushi, > > Are you trying to install rubygems running MSYS console or what? I > fully don't understand your question, but it seems is related to how > path is being split. > > Can you provide more information about the ruby version, the MinGW and > the console (MSYS or plain cmd.exe), Windows version and version of > MinGW stuff you're trying to get it installed into? > > Regards, > -- > Luis Lavena > AREA 17 > - > Human beings, who are almost unique in having the ability to learn from > the experience of others, are also remarkable for their apparent > disinclination to do so. > Douglas Adams > _______________________________________________ > Rubygems-developers mailing list > Rubygems-developers at rubyforge.org > http://rubyforge.org/mailman/listinfo/rubygems-developers From luislavena at gmail.com Fri Jun 6 08:32:52 2008 From: luislavena at gmail.com (Luis Lavena) Date: Fri, 6 Jun 2008 09:32:52 -0300 Subject: [Rubygems-developers] How to install rubygems on MinGW? In-Reply-To: <200806061105.m56B57pM021781@fjmscan502.ms.jp.fujitsu.com> References: <71166b3b0806060238q728b7440w797516fb65889641@mail.gmail.com> <200806061105.m56B57pM021781@fjmscan502.ms.jp.fujitsu.com> Message-ID: <71166b3b0806060532h97ec041i449e96ce8398e2b6@mail.gmail.com> On Fri, Jun 6, 2008 at 8:05 AM, Atsushi SAKAI wrote: > Hi, Luis > > Thank your for quick response. > > I am trying to install rubygems running MSYS console (rxvt). > > Ruby version is ruby 1.8.4 (2005-12-24) [i386-minw32] > Now I am using Windows XP. > and MinGW is (from gcc) gcc.exe (GCC) 3.4.5 (mingw special) > > I do someting wrong? > Actually is hard to track, from the backtrace references looks like you're trying to install rubygems into msys setup, and I suppose that's maybe you installed ruby (mingw build) in there too. Are you using Rubygems 1.1.1 package from the rubyforge page [1] or using the svn version? Also, from where did you get the 1.8.4 version of Ruby you're using? are you sure is mingw32 and not cygwin? 1.8.4 sounds familiar to me for my cygwin battle days, but can be wrong (which usually happens). Can you provide me with the list of steps you did until you got this issue? (installed mingw, msys, ruby, etc, and where you pick those files) so I can pinpoint where and what is the real problem. Regards, -- Luis Lavena AREA 17 - Human beings, who are almost unique in having the ability to learn from the experience of others, are also remarkable for their apparent disinclination to do so. Douglas Adams From sakaia at jp.fujitsu.com Fri Jun 6 09:08:59 2008 From: sakaia at jp.fujitsu.com (Atsushi SAKAI) Date: Fri, 06 Jun 2008 22:08:59 +0900 Subject: [Rubygems-developers] How to install rubygems on MinGW? In-Reply-To: <71166b3b0806060532h97ec041i449e96ce8398e2b6@mail.gmail.com> References: <71166b3b0806060532h97ec041i449e96ce8398e2b6@mail.gmail.com> Message-ID: <200806061309.m56D92ON026923@fjmscan503.ms.jp.fujitsu.com> Thank you for commenting this. I agree this is hard to track. and also My environment instruction is very complicated. I clean up my instruction and posting again. Thanks Atsushi SAKAI "Luis Lavena" wrote: > On Fri, Jun 6, 2008 at 8:05 AM, Atsushi SAKAI wrote: > > Hi, Luis > > > > Thank your for quick response. > > > > I am trying to install rubygems running MSYS console (rxvt). > > > > Ruby version is ruby 1.8.4 (2005-12-24) [i386-minw32] > > Now I am using Windows XP. > > and MinGW is (from gcc) gcc.exe (GCC) 3.4.5 (mingw special) > > > > I do someting wrong? > > > > Actually is hard to track, from the backtrace references looks like > you're trying to install rubygems into msys setup, and I suppose > that's maybe you installed ruby (mingw build) in there too. > > Are you using Rubygems 1.1.1 package from the rubyforge page [1] or > using the svn version? > > Also, from where did you get the 1.8.4 version of Ruby you're using? > are you sure is mingw32 and not cygwin? 1.8.4 sounds familiar to me > for my cygwin battle days, but can be wrong (which usually happens). > > Can you provide me with the list of steps you did until you got this > issue? (installed mingw, msys, ruby, etc, and where you pick those > files) so I can pinpoint where and what is the real problem. > > Regards, > -- > Luis Lavena > AREA 17 > - > Human beings, who are almost unique in having the ability to learn from > the experience of others, are also remarkable for their apparent > disinclination to do so. > Douglas Adams > _______________________________________________ > Rubygems-developers mailing list > Rubygems-developers at rubyforge.org > http://rubyforge.org/mailman/listinfo/rubygems-developers From drbrain at segment7.net Fri Jun 6 17:04:09 2008 From: drbrain at segment7.net (Eric Hodel) Date: Fri, 6 Jun 2008 14:04:09 -0700 Subject: [Rubygems-developers] How to install rubygems on MinGW? In-Reply-To: <200806060913.m569D4OU021980@fjmscan502.ms.jp.fujitsu.com> References: <200806060913.m569D4OU021980@fjmscan502.ms.jp.fujitsu.com> Message-ID: On Jun 6, 2008, at 02:13 AM, Atsushi SAKAI wrote: > I have a question about rubygems to install MinGW. > > If this mailing list is wrong for this issue, > Please suggest me. > > I am trying to do ruby setup.py, > but it generates many error message like follows. > If any good page exists, please suggest me. > > ================= > install -c -m 0755 C:/DOCUME~1/ADMINI~1/LOCALS~1/Temp/gem.bat C:/ > msys/1.0/local/bin/gem.bat > rm C:/DOCUME~1/ADMINI~1/LOCALS~1/Temp/gem.bat > rm -f C:/msys/1.0/local/lib/ruby/gems/1.8/source_cache > rm -rf C:/msys/1.0/local/lib/ruby/gems/1.8/doc/rubygems-1.1.1 > > lib/rubygems/command_manager.rb:139:61: Skipping require of dynamic > string: "rubygems/commands/#{command_name}_command" > > lib/rubygems/dependency_installer.rb:38:5: Unrecognized directive > 'env_shebang' > > lib/rubygems/installer.rb:59:5: Unrecognized directive 'env_shebang' > > lib/rubygems/install_update_options.rb:22:32: ':' not followed by > identified or operator > > lib/rubygems/install_update_options.rb:28:32: ':' not followed by > identified or operator These warning come from RDoc, so your installation should be complete if these are the only ones. From drbrain at segment7.net Sun Jun 8 01:20:37 2008 From: drbrain at segment7.net (Eric Hodel) Date: Sat, 7 Jun 2008 22:20:37 -0700 Subject: [Rubygems-developers] Problems with trunk (rev 1708) - server source index refresh losing config-file overrides In-Reply-To: References: Message-ID: <1915B60A-5680-4E68-8C94-A2F56D716C42@segment7.net> On Jun 5, 2008, at 21:40 PM, Chad Woolley wrote: > On Tue, Jun 3, 2008 at 11:30 PM, Chad Woolley > wrote: >> opened a bug here: >> http://rubyforge.org/tracker/index.php?func=detail&aid=20509&group_id=126&atid=575 > > Update on this. config-file seems to be a red herring. Real problem > is that the trunk "gem list --remote" is reporting local system gems > that are not in the servers dir, when the list command is run the > *second* time. See details with commands to reproduce on the ticket. > > Anyone else seeing this? Fixed in 1756. I made Gem::SourceIndex track where it got loaded from, so #refresh! will always refresh from the same paths. (It also now raises if the SourceIndex wasn't created from a directory.) From thewoolleyman at gmail.com Sun Jun 8 02:49:22 2008 From: thewoolleyman at gmail.com (Chad Woolley) Date: Sat, 7 Jun 2008 23:49:22 -0700 Subject: [Rubygems-developers] Problems with trunk (rev 1708) - server source index refresh losing config-file overrides In-Reply-To: <1915B60A-5680-4E68-8C94-A2F56D716C42@segment7.net> References: <1915B60A-5680-4E68-8C94-A2F56D716C42@segment7.net> Message-ID: On Sat, Jun 7, 2008 at 10:20 PM, Eric Hodel wrote: > Fixed in 1756. > > I made Gem::SourceIndex track where it got loaded from, so #refresh! will > always refresh from the same paths. (It also now raises if the SourceIndex > wasn't created from a directory.) Thanks. I'd been trying to debug it, but you are faster :) Now I'm getting some different errors out of my tests (gem_command_manager_spec), like "uninitialized constant Gem::SourceInfoCache" (I am clearing it manually in some tests, not sure why it's no longer getting required), and "source index not created from disk" (not sure what that means). I'll try to look into these soon. I'd like to get all my tests passing against trunk before you release. -- Chad From drbrain at segment7.net Sun Jun 8 03:58:48 2008 From: drbrain at segment7.net (Eric Hodel) Date: Sun, 8 Jun 2008 00:58:48 -0700 Subject: [Rubygems-developers] SourceInfoCache gone, etc. (Was: Problems with trunk ...) In-Reply-To: References: <1915B60A-5680-4E68-8C94-A2F56D716C42@segment7.net> Message-ID: <6806E41C-F7EF-4933-A706-2589129DD2D8@segment7.net> On Jun 7, 2008, at 23:49 PM, Chad Woolley wrote: > On Sat, Jun 7, 2008 at 10:20 PM, Eric Hodel > wrote: >> Fixed in 1756. >> >> I made Gem::SourceIndex track where it got loaded from, so >> #refresh! will >> always refresh from the same paths. (It also now raises if the >> SourceIndex >> wasn't created from a directory.) > > Thanks. I'd been trying to debug it, but you are faster :) > > Now I'm getting some different errors out of my tests > (gem_command_manager_spec), like "uninitialized constant > Gem::SourceInfoCache" (I am clearing it manually in some tests, not > sure why it's no longer getting required), SourceInfoCache only gets required if RubyGems hits a source without specs.4.8.gz or latest_specs.4.8.gz. For your tests you'll need to require it by hand now. The new bulk-index-free API is in rubygems/spec_fetcher.rb (Gem::SpecFetcher). > and "source index not created from disk" (not sure what that means). Gem::SourceIndex#refresh! raises if the SourceIndex wasn't created from a spec dir (::from_installed_gems and ::from_gems_in create a SourceIndex from a directory). I added this to prevent future occurrences of the error you found in Gem::Server, but I could change it back to pulling from the installation dirs like it did before. From thewoolleyman at gmail.com Sun Jun 8 14:34:29 2008 From: thewoolleyman at gmail.com (Chad Woolley) Date: Sun, 8 Jun 2008 11:34:29 -0700 Subject: [Rubygems-developers] SourceInfoCache gone, etc. (Was: Problems with trunk ...) In-Reply-To: <6806E41C-F7EF-4933-A706-2589129DD2D8@segment7.net> References: <1915B60A-5680-4E68-8C94-A2F56D716C42@segment7.net> <6806E41C-F7EF-4933-A706-2589129DD2D8@segment7.net> Message-ID: On Sun, Jun 8, 2008 at 12:58 AM, Eric Hodel wrote: > The new bulk-index-free API is in rubygems/spec_fetcher.rb > (Gem::SpecFetcher). OK, I'd like to clarify a few things about the latest version: 1. Should ANY remote queries via the API should go through spec_fetcher.rb? 2. Should there be any reason to directly use SourceIndex anymore, or should it be considered private? 3. Should all this work the same for the on-the-fly servers (quick index is the right term?) as well as servers with generated specs.4.8.gz/latest_specs.4.8.gz? Thanks for your work on this, -- Chad From thewoolleyman at gmail.com Sun Jun 8 18:19:42 2008 From: thewoolleyman at gmail.com (Chad Woolley) Date: Sun, 8 Jun 2008 15:19:42 -0700 Subject: [Rubygems-developers] SourceInfoCache gone, etc. (Was: Problems with trunk ...) In-Reply-To: References: <1915B60A-5680-4E68-8C94-A2F56D716C42@segment7.net> <6806E41C-F7EF-4933-A706-2589129DD2D8@segment7.net> Message-ID: On Sun, Jun 8, 2008 at 11:34 AM, Chad Woolley wrote: > 1. Should ANY remote queries via the API ... Correction, I meant 'local" queries, not remote. I assume GemRunner with --list --remote options is still correct for remote queries. From rf at 7syntax.com Mon Jun 9 06:41:32 2008 From: rf at 7syntax.com (Ruben Fonseca) Date: Mon, 09 Jun 2008 11:41:32 +0100 Subject: [Rubygems-developers] gem weirdness Message-ID: <1213008091.9961.8.camel@replicator.local> ? Hi @all! :) I have a project at rubyforge called tarpipe (tarpipe.rubyforge.org). It's already at version 0.1.1. However, I found today that when I do on any machine "sudo gem install tarpipe" it installs a gem version 0.0.1 that *is not even my code*! It's a different project by a different author! So I have two questions: - How is this possible? - What can I do to correct this situation! Thank you for your support Ruben From jim.weirich at gmail.com Mon Jun 9 08:59:03 2008 From: jim.weirich at gmail.com (Jim Weirich) Date: Mon, 9 Jun 2008 06:59:03 -0600 Subject: [Rubygems-developers] gem weirdness In-Reply-To: <1213008091.9961.8.camel@replicator.local> References: <1213008091.9961.8.camel@replicator.local> Message-ID: On Jun 9, 2008, at 4:41 AM, Ruben Fonseca wrote: > I have a project at rubyforge called tarpipe (tarpipe.rubyforge.org). > It's already at version 0.1.1. > > However, I found today that when I do on any machine "sudo gem install > tarpipe" it installs a gem version 0.0.1 that *is not even my code*! > It's a different project by a different author! > > So I have two questions: > > - How is this possible? > - What can I do to correct this situation! I see the author of verion 0.0.1 is listed as a co-owner of the tarpipe project. I see the 0.1.1 gem listed in the files area, but no 0.0.1 version. Did you or he release version 0.0.1 from a different project? Once a gem is released, you must upload new versions to the same project name (this protects you from someone else releasing a gem with the same name and overriding yours). If this is the case, then you just need to file a support ticket with RubyForge to get that switched. -- -- Jim Weirich -- jim.weirich at gmail.com From jftucker at gmail.com Mon Jun 9 09:49:01 2008 From: jftucker at gmail.com (James Tucker) Date: Mon, 9 Jun 2008 14:49:01 +0100 Subject: [Rubygems-developers] gem weirdness In-Reply-To: References: <1213008091.9961.8.camel@replicator.local> Message-ID: <31D03683-909C-487D-8073-FD0B8A8A4F82@gmail.com> On 9 Jun 2008, at 13:59, Jim Weirich wrote: > On Jun 9, 2008, at 4:41 AM, Ruben Fonseca wrote: >> I have a project at rubyforge called tarpipe (tarpipe.rubyforge.org). >> It's already at version 0.1.1. >> >> However, I found today that when I do on any machine "sudo gem >> install >> tarpipe" it installs a gem version 0.0.1 that *is not even my code*! >> It's a different project by a different author! >> >> So I have two questions: >> >> - How is this possible? >> - What can I do to correct this situation! > > > I see the author of verion 0.0.1 is listed as a co-owner of the > tarpipe project. I see the 0.1.1 gem listed in the files area, but > no 0.0.1 version. Did you or he release version 0.0.1 from a > different project? Once a gem is released, you must upload new > versions to the same project name (this protects you from someone > else releasing a gem with the same name and overriding yours). If > this is the case, then you just need to file a support ticket with > RubyForge to get that switched. Mmm.. pay close attention to the e-mail addresses on the site, are they correct? http://tarpipe.rubyforge.org/ > > > -- > -- Jim Weirich > -- jim.weirich at gmail.com > > _______________________________________________ > Rubygems-developers mailing list > Rubygems-developers at rubyforge.org > http://rubyforge.org/mailman/listinfo/rubygems-developers From drbrain at segment7.net Mon Jun 9 12:36:21 2008 From: drbrain at segment7.net (Eric Hodel) Date: Mon, 9 Jun 2008 09:36:21 -0700 Subject: [Rubygems-developers] SourceInfoCache gone, etc. (Was: Problems with trunk ...) In-Reply-To: References: <1915B60A-5680-4E68-8C94-A2F56D716C42@segment7.net> <6806E41C-F7EF-4933-A706-2589129DD2D8@segment7.net> Message-ID: <372210E1-DAD7-4680-B78E-420F6FC85655@segment7.net> On Jun 8, 2008, at 11:34 AM, Chad Woolley wrote: > On Sun, Jun 8, 2008 at 12:58 AM, Eric Hodel > wrote: >> The new bulk-index-free API is in rubygems/spec_fetcher.rb >> (Gem::SpecFetcher). > > OK, I'd like to clarify a few things about the latest version: > > 1. Should ANY [local] queries via the API should go through > spec_fetcher.rb? No, they still use Gem.source_index. See Gem::Commands::QueryCommand#execute. > 2. Should there be any reason to directly use SourceIndex anymore, or > should it be considered private? Gem::SourceIndex is ok to use, but Gem::SourceInfoCache and Gem::SourceInfoCacheEntry will be going away eventually (probably in 2 years or so). > 3. Should all this work the same for the on-the-fly servers (quick > index is the right term?) as well as servers with generated > specs.4.8.gz/latest_specs.4.8.gz? Both `gem server` and `gem generate_index` now produce specs.4.8.gz and latest_specs.4.8.gz, and they also produce all the legacy indexes. If there's a server without the new indexes all the sources should drop back to using the legacy indexes (and print out a warning). From drbrain at segment7.net Mon Jun 9 13:03:09 2008 From: drbrain at segment7.net (Eric Hodel) Date: Mon, 9 Jun 2008 10:03:09 -0700 Subject: [Rubygems-developers] gem weirdness In-Reply-To: <1213008091.9961.8.camel@replicator.local> References: <1213008091.9961.8.camel@replicator.local> Message-ID: <15145184-6061-454F-9601-2C622D674B1C@segment7.net> On Jun 9, 2008, at 03:41 AM, Ruben Fonseca wrote: > I have a project at rubyforge called tarpipe (tarpipe.rubyforge.org). > It's already at version 0.1.1. > > However, I found today that when I do on any machine "sudo gem install > tarpipe" it installs a gem version 0.0.1 that *is not even my code*! > It's a different project by a different author! > > So I have two questions: > > - How is this possible? Since tarpipe-0.0.1 is not in your files list, it was probably added to the index manually by Tom Copeland. If a gem was added manually, gems with a name collision won't be added to prevent people from doing malicious stuff. > - What can I do to correct this situation! Put tarpipe-0.0.1 in your downloads list (optional) and have Tom (tom at infoether.com ) remove tarpipe-0.0.1 that was manually added. From bret at pettichord.com Mon Jun 9 17:43:45 2008 From: bret at pettichord.com (Bret Pettichord) Date: Mon, 9 Jun 2008 16:43:45 -0500 Subject: [Rubygems-developers] Help with Gem Dependencies In-Reply-To: References: Message-ID: > Also, I'd be interested to hear what sort of bugs you're encountering > in 1.8.6. Send an email to the rubyinstaller (One Click Installer > project for Windows) mailing list. > http://rubyforge.org/mail/?group_id=167 Looks like the main problem that was keeping me from 1.8.6 is fixed in windows version 1.8.6-26, so i will be installing that and if that works, i'll be recommending this for Watir users. Thanks for suggestions. Bret -- Bret Pettichord CTO, WatirCraft LLC Lead Developer, Watir, http://wtr.rubyforge.org Blog (Essays), http://www.io.com/~wazmo/blog MiniBlog (Links), http://feeds.feedburner.com/bretshotlist From thewoolleyman at gmail.com Tue Jun 10 01:42:51 2008 From: thewoolleyman at gmail.com (Chad Woolley) Date: Mon, 9 Jun 2008 22:42:51 -0700 Subject: [Rubygems-developers] trunk bug: incompatible marshall file format when --list --details Message-ID: When I pass the --details option to --list --remote, I get this error: ERROR: While executing gem ... (TypeError) incompatible marshal file format (can't be read) format version 4.8 required; 45.45 given Let me know if you need more details to reproduce. From drbrain at segment7.net Tue Jun 10 14:26:01 2008 From: drbrain at segment7.net (Eric Hodel) Date: Tue, 10 Jun 2008 11:26:01 -0700 Subject: [Rubygems-developers] trunk bug: incompatible marshall file format when --list --details In-Reply-To: References: Message-ID: <38FF3611-79CC-4DCA-9AE6-CCD1B5B208B1@segment7.net> On Jun 9, 2008, at 22:42 PM, Chad Woolley wrote: > When I pass the --details option to --list --remote, I get this error: > > ERROR: While executing gem ... (TypeError) > incompatible marshal file format (can't be read) > format version 4.8 required; 45.45 given > > Let me know if you need more details to reproduce. I cannot reproduce. Looks like something got confused and you downloaded a yaml file instead. $ ruby -e 'p 45.chr; Marshal.load "--"' "-" -e:1:in `load': incompatible marshal file format (can't be read) (TypeError) format version 4.8 required; 45.45 given from -e:1 I see: $ svnversion 1761M [minor change] $ ruby -Ilib bin/gem sources -c *** Removed specs cache *** *** Removed user source cache *** *** Removed latest user source cache *** *** Removed system source cache *** *** Removed latest system source cache *** $ ruby -Ilib bin/gem list -r -d rails -V *** REMOTE GEMS *** GET 200 OK: http://gems.rubyforge.org/latest_specs.4.8.gz GET 200 OK: http://gems.rubyforge.org/quick/Marshal.4.8/rails-2.1.0.gemspec.rz [...] rails (2.1.0) Author: David Heinemeier Hansson Rubyforge: http://rubyforge.org/projects/rails Homepage: http://www.rubyonrails.org Web-application framework with template engine, control-flow layer, and ORM. [...] $ From rf at 7syntax.com Wed Jun 11 04:16:20 2008 From: rf at 7syntax.com (Ruben Fonseca) Date: Wed, 11 Jun 2008 09:16:20 +0100 Subject: [Rubygems-developers] gem weirdness In-Reply-To: References: <1213008091.9961.8.camel@replicator.local> Message-ID: <1213172180.22051.2.camel@replicator.local> On Mon, 2008-06-09 at 06:59 -0600, Jim Weirich wrote: > On Jun 9, 2008, at 4:41 AM, Ruben Fonseca wrote: > > I have a project at rubyforge called tarpipe (tarpipe.rubyforge.org). > > It's already at version 0.1.1. > > > > However, I found today that when I do on any machine "sudo gem install > > tarpipe" it installs a gem version 0.0.1 that *is not even my code*! > > It's a different project by a different author! > > > > So I have two questions: > > > > - How is this possible? > > - What can I do to correct this situation! > > > I see the author of verion 0.0.1 is listed as a co-owner of the > tarpipe project. I see the 0.1.1 gem listed in the files area, but no > 0.0.1 version. Did you or he release version 0.0.1 from a different > project? Yes indeed it was the case. He did release a first version a few hours earlier, but then he merged his work with mine and we release under tarpipe.rubyforge.org I opened a support request ticket as you said... now we just wait :) Thank you for your support Ruben From tom at infoether.com Wed Jun 11 13:12:10 2008 From: tom at infoether.com (Tom Copeland) Date: Wed, 11 Jun 2008 13:12:10 -0400 Subject: [Rubygems-developers] gem weirdness In-Reply-To: <1213172180.22051.2.camel@replicator.local> References: <1213008091.9961.8.camel@replicator.local> <1213172180.22051.2.camel@replicator.local> Message-ID: <1213204330.2938.11.camel@localhost.localdomain> On Wed, 2008-06-11 at 09:16 +0100, Ruben Fonseca wrote: > Yes indeed it was the case. He did release a first version a few hours > earlier, but then he merged his work with mine and we release under > tarpipe.rubyforge.org > > I opened a support request ticket as you said... now we just wait :) Sorry for the delay - I just moved and don't have internet access at home yet, so I have to do RubyForge stuff in between customer work... doh. Anyhow, should be all set now: =========================== $ gem list --remote tarpipe *** REMOTE GEMS *** Bulk updating Gem source index for: http://gems.rubyforge.org/ tarpipe (0.1.1) =========================== Yours, Tom From ryand-ruby at zenspider.com Wed Jun 11 14:19:31 2008 From: ryand-ruby at zenspider.com (Ryan Davis) Date: Wed, 11 Jun 2008 11:19:31 -0700 Subject: [Rubygems-developers] bulk updating bug In-Reply-To: <1213204330.2938.11.camel@localhost.localdomain> References: <1213008091.9961.8.camel@replicator.local> <1213172180.22051.2.camel@replicator.local> <1213204330.2938.11.camel@localhost.localdomain> Message-ID: On Jun 11, 2008, at 10:12 , Tom Copeland wrote: > Anyhow, should be all set now: > > =========================== > $ gem list --remote tarpipe > > *** REMOTE GEMS *** > > Bulk updating Gem source index for: http://gems.rubyforge.org/ > tarpipe (0.1.1) > =========================== Can we PLEASE address the bulk updating issue? It has to be a 1-line bug: 501 % gem list --remote tarpipe *** REMOTE GEMS *** Bulk updating Gem source index for: http://gems.rubyforge.org/ tarpipe (0.1.1) 502 % gem list --remote tarpipe *** REMOTE GEMS *** Bulk updating Gem source index for: http://gems.rubyforge.org/ tarpipe (0.1.1) 502 % sudo gem list --remote tarpipe Password: *** REMOTE GEMS *** Bulk updating Gem source index for: http://gems.rubyforge.org/ tarpipe (0.1.1) 503 % sudo gem list --remote tarpipe *** REMOTE GEMS *** Bulk updating Gem source index for: http://gems.rubyforge.org/ tarpipe (0.1.1) 503 % gem -v 1.1.1 From chris.zhu at sun.com Thu Jun 12 23:56:22 2008 From: chris.zhu at sun.com (Chris Zhu) Date: Fri, 13 Jun 2008 11:56:22 +0800 Subject: [Rubygems-developers] Is there any man page ready for rubygem Message-ID: <4851EFE6.1010603@sun.com> Hi all, We can find man page for ruby which is delivered in ruby source code by default, how about gem, is there any man page ready for rubygem. Regards Chris From devi.webmaster at gmail.com Fri Jun 13 19:12:06 2008 From: devi.webmaster at gmail.com (Daniel Brumbaugh Keeney) Date: Fri, 13 Jun 2008 18:12:06 -0500 Subject: [Rubygems-developers] Is there any man page ready for rubygem In-Reply-To: <4851EFE6.1010603@sun.com> References: <4851EFE6.1010603@sun.com> Message-ID: <3bceeb2d0806131612g50620334w1e4edd6e6964204b@mail.gmail.com> On Thu, Jun 12, 2008 at 10:56 PM, Chris Zhu wrote: > Is there any man page ready for rubygem? I do not believe there is an official man page for RubyGems. However, RubyGems is intended to include documentation with the command `gem help`. If for some reason you need a man page, several Linux distros require them (eg. Debian ) and have written simple ones. Daniel Brumbaugh Keeney For your convenience, I have attached the man page I found in the Ubuntu RubyGems package. -------------- next part -------------- A non-text attachment was scrubbed... Name: gem.1.gz Type: application/x-gzip Size: 444 bytes Desc: not available URL: From drbrain at segment7.net Sun Jun 15 17:57:07 2008 From: drbrain at segment7.net (Eric Hodel) Date: Sun, 15 Jun 2008 14:57:07 -0700 Subject: [Rubygems-developers] trunk bug: incompatible marshall file format when --list --details In-Reply-To: References: Message-ID: <4BA207A0-70BF-4530-9CC6-E3ECBB2158CD@segment7.net> On Jun 9, 2008, at 22:42 PM, Chad Woolley wrote: > When I pass the --details option to --list --remote, I get this error: > > ERROR: While executing gem ... (TypeError) > incompatible marshal file format (can't be read) > format version 4.8 required; 45.45 given > > Let me know if you need more details to reproduce. Fixed in 1762. When a platform was present an additional =~ was called clearing $1 that was being used to track marshal vs yaml formats. From chris.zhu at sun.com Sun Jun 15 23:18:32 2008 From: chris.zhu at sun.com (Chris Zhu) Date: Mon, 16 Jun 2008 11:18:32 +0800 Subject: [Rubygems-developers] Is there any man page ready for rubygem In-Reply-To: <3bceeb2d0806131612g50620334w1e4edd6e6964204b@mail.gmail.com> References: <4851EFE6.1010603@sun.com> <3bceeb2d0806131612g50620334w1e4edd6e6964204b@mail.gmail.com> Message-ID: <4855DB88.4020804@sun.com> An HTML attachment was scrubbed... URL: From hongli at phusion.nl Mon Jun 16 05:07:48 2008 From: hongli at phusion.nl (Hongli Lai) Date: Mon, 16 Jun 2008 11:07:48 +0200 Subject: [Rubygems-developers] HEADSUP RubyGems 1.2 Real Soon Now Message-ID: <48562D64.2090306@phusion.nl> Ryan Davis wrote: > Donavan Pantke wrote: > > The :install flag is required for gems that have specific loading > > requirements, and so cannot have dependencies automatically > > activated. The > > biggest use case is Passenger, which can activate multiple versions > > of Rails. > > It originally required rails in the gemspec (as it needs some > > version of > > Rails), but that meant that when the passenger gem activated, rails > > automatically activated as well. That caused passenger to blow up > > when trying > > to activate a different version of Rails. Having the :install flag > > will allow > > Passenger to be loaded but let Passenger worry about Rails. > > Biggest use-case, or only use-case? I suspect it is the latter and as > such think that adding it is more confusing than leaving it out. It is > incredibly hard to explain (this thread is evidence) and I can easily > imagine it being misused more than it helps. I have to agree. I too believe that Phusion Passenger is the only use case, although Mongrel *could* be a use case because they too have to support multiple Rails version. The reason why Rails was originally included in the gem spec as a dependency, is to save the user some typing. But in retrospect, it probably was unnecessary, because: 1. Everybody's running different apps, so everybody will need different versions of Rails. Installing 2.0 for them automatically will probably only benefit a small part of the user base. And the only benefit is not having to type in an extra 'gem install' command. 2. If a required Rails version is not installed, then Phusion Passenger will display a nicely formatted error page, which includes the exact gem command to run for installing that version of Rails. I think the costs of implementing :install outweight the (tiny) benefits. Regards, Hongli Lai -- Phusion | The Computer Science Company Web: http://www.phusion.nl/ E-mail: info at phusion.nl Chamber of commerce no: 08173483 (The Netherlands) From drbrain at segment7.net Mon Jun 16 20:58:05 2008 From: drbrain at segment7.net (Eric Hodel) Date: Mon, 16 Jun 2008 17:58:05 -0700 Subject: [Rubygems-developers] RubyGems 1.2.0 release in less than one week Message-ID: I would like to release a RubyGems by the end of the week, but on Monday at latest. Please test revision 1772 of trunk. Windows users, please check out Gem::ConfigFile::SYSTEM_WIDE_CONFIG_FILE to make sure it is correct. I pulled this code from an email from Daniel Berger of several months ago. I'll be contacting the operators of gems.rubyonrails.org and gems.github.com to give them a heads-up about the upcoming release so they can update to the new rubygems as close to the release announcement as possible. Here is a draft of the 1.2.0 release notes, let me know if I missed anything. New features: * RubyGems no longer performs bulk updates and instead only fetches the gemspec files it needs. Alternate sources will need to upgrade to RubyGems 1.2 to allow RubyGems to take advantage of the new metadata updater. If a pre 1.2 remote source is in the sources list, RubyGems will revert to the bulk update code for compatibility. * RubyGems now has runtime and development dependency types. Use #add_development_dependency and #add_runtime_dependency. All typeless dependencies are considered to be development dependencies. * RubyGems will now require rubygems/defaults/operating_system.rb and rubygems/defaults/#{RBX_ENGINE}.rb if they exist. This allows packagers and ruby implementers to add custom behavior to RubyGems via these files. * /etc/gemrc (and windows equivalent) for global settings * setup.rb now handles --vendor and --destdir for packagers * `gem stale` command that lists gems by last access time Bugs Fixed: * `gem install --no-wrappers` followed by `gem install --wrappers` no longer overwrites executables * `gem pristine` now forces reinstallation of gems, bug #20387 * A trailing / is now added to remote sources when missing, bug #20134 * RubyGems gracefully handles ^C while loading .gemspec files from disk, bug #20523 * Paths are expanded in more places, bug #19317, bug #19896 * Gem::DependencyInstaller resets installed gems every install, bug #19444 * Gems with legacy platforms will now be correctly uninstalled, patch #19877 * Gem.default_path is now honored if GEM_PATH is not set, patch #19502 * File modes from gems are now honored, patch #19737 Other Changes Include: * setup.rb * stub files created by RubyGems 0.7.x and older are no longer removed. When upgrading from these ancient versions, upgrade to 1.1.x first to clean up stubs. * RDoc is no longer required untill necessary, patch #20414 * `gem server` * Now completely matches the output of `gem generate_index` and has correct content types * Refreshes from source directories for every hit. The server will no longer need to be restarted after installing gems. * `gem query --details` and friends now display author, homepage, rubyforge url and installed location * `gem install` without -i no longer reinstalls dependencies if they are in GEM_PATH and not in GEM_HOME * Gem::RemoteFetcher now performs persistent connections for HEAD requests, bug #7973 For a full list of changes to RubyGems and the contributor for each change, see the ChangeLog file. From jbarnette at gmail.com Mon Jun 16 21:00:54 2008 From: jbarnette at gmail.com (John Barnette) Date: Mon, 16 Jun 2008 18:00:54 -0700 Subject: [Rubygems-developers] RubyGems 1.2.0 release in less than one week In-Reply-To: References: Message-ID: <2bce3eb60806161800y3f8ada7bi7106d00de43ab570@mail.gmail.com> On Mon, Jun 16, 2008 at 5:58 PM, Eric Hodel wrote: > * RubyGems now has runtime and development dependency types. Use > #add_development_dependency and #add_runtime_dependency. All typeless > dependencies are considered to be development dependencies. When I originally implemented this, typeless dependencies were considered to be *runtime* dependencies, not development. This was to provide backwards compatibility for older gemspecs. Did this change? ~ j. From jbarnette at gmail.com Mon Jun 16 21:00:54 2008 From: jbarnette at gmail.com (John Barnette) Date: Mon, 16 Jun 2008 18:00:54 -0700 Subject: [Rubygems-developers] RubyGems 1.2.0 release in less than one week In-Reply-To: References: Message-ID: <2bce3eb60806161800y3f8ada7bi7106d00de43ab570@mail.gmail.com> On Mon, Jun 16, 2008 at 5:58 PM, Eric Hodel wrote: > * RubyGems now has runtime and development dependency types. Use > #add_development_dependency and #add_runtime_dependency. All typeless > dependencies are considered to be development dependencies. When I originally implemented this, typeless dependencies were considered to be *runtime* dependencies, not development. This was to provide backwards compatibility for older gemspecs. Did this change? ~ j. From thewoolleyman at gmail.com Mon Jun 16 22:12:56 2008 From: thewoolleyman at gmail.com (Chad Woolley) Date: Mon, 16 Jun 2008 19:12:56 -0700 Subject: [Rubygems-developers] Problems with dependency command Message-ID: trunk is looking good, but found some strangeness with the 'dependency' command. First, though, a question: How should the '--remote' and '--source XXX' options interact, in general? Does --source without --remote imply --remote? It seems like this behaves differently for the dependency command vs. the list command, but I may be confused. In prior versions, it seems like --remote was always required, and --source would have no effect if remote was not there. Is this still the case? Anyway, here is the reproducible bug with dependency. It shows a successful remote list with trunk, then a dependency command failure with trunk, then the same dependency command successful with 1.1.1. Thanks... chadmac:rubygems woolley$ rm -rf ~/.gem; ruby -I ./lib:./bin ./bin/gem list ruby-doom --remote *** REMOTE GEMS *** ruby-doom (0.8.0) chadmac:rubygems woolley$ rm -rf ~/.gem; ruby -I ./lib:./bin ./bin/gem --backtrace dependency ruby-doom --remote ERROR: While executing gem ... (Gem::RemoteFetcher::FetchError) bad response Not Found 404 (http://gems.rubyforge.org/quick/Marshal.4.8/ruby-doom-0.8.0.gemspec.rz) ./lib/rubygems/remote_fetcher.rb:264:in `open_uri_or_path' ./lib/rubygems/remote_fetcher.rb:136:in `fetch_path' ./lib/rubygems/spec_fetcher.rb:92:in `fetch_spec' ./lib/rubygems/commands/dependency_command.rb:72:in `execute' ./lib/rubygems/commands/dependency_command.rb:71:in `each' ./lib/rubygems/commands/dependency_command.rb:71:in `execute' ./lib/rubygems/command.rb:136:in `invoke' ./lib/rubygems/command_manager.rb:105:in `process_args' ./lib/rubygems/command_manager.rb:75:in `run' ./lib/rubygems/gem_runner.rb:39:in `run' ./bin/gem:24 chadmac:rubygems woolley$ gem --version 1.1.1 chadmac:rubygems woolley$ gem --backtrace dependency ruby-doom --remote Bulk updating Gem source index for: http://gems.rubyforge.org/ Gem ruby-doom-0.8 From drbrain at segment7.net Tue Jun 17 04:20:16 2008 From: drbrain at segment7.net (Eric Hodel) Date: Tue, 17 Jun 2008 01:20:16 -0700 Subject: [Rubygems-developers] Problems with dependency command In-Reply-To: References: Message-ID: On Jun 16, 2008, at 19:12 PM, Chad Woolley wrote: > trunk is looking good, but found some strangeness with the > 'dependency' command. > > First, though, a question: How should the '--remote' and '--source > XXX' options interact, in general? Does --source without --remote > imply --remote? It seems like this behaves differently for the > dependency command vs. the list command, but I may be confused. In > prior versions, it seems like --remote was always required, and > --source would have no effect if remote was not there. Is this still > the case? Currently --source does not imply --remote, and I don't believe it ever did. However, --both (local and remote) is the default unless overridden, which it is for at least query, list, search and dep. If you supply --source, you'll need to --remote for at least these commands. > Anyway, here is the reproducible bug with dependency. It shows a > successful remote list with trunk, then a dependency command failure > with trunk, then the same dependency command successful with 1.1.1. > Thanks... > > chadmac:rubygems woolley$ rm -rf ~/.gem; ruby -I ./lib:./bin ./bin/gem > --backtrace dependency ruby-doom --remote > ERROR: While executing gem ... (Gem::RemoteFetcher::FetchError) > bad response Not Found 404 > (http://gems.rubyforge.org/quick/Marshal.4.8/ruby-doom-0.8.0.gemspec.rz > ) Fixed in r1773, but will need Tom to update the indexer code before it will work for you. From drbrain at segment7.net Tue Jun 17 14:02:55 2008 From: drbrain at segment7.net (Eric Hodel) Date: Tue, 17 Jun 2008 11:02:55 -0700 Subject: [Rubygems-developers] RubyGems 1.2.0 release in less than one week In-Reply-To: <2bce3eb60806161800y3f8ada7bi7106d00de43ab570@mail.gmail.com> References: <2bce3eb60806161800y3f8ada7bi7106d00de43ab570@mail.gmail.com> Message-ID: <1B53EFC3-CCA4-48DD-A496-23935BF462D4@segment7.net> On Jun 16, 2008, at 18:00 PM, John Barnette wrote: > On Mon, Jun 16, 2008 at 5:58 PM, Eric Hodel > wrote: >> * RubyGems now has runtime and development dependency types. Use >> #add_development_dependency and #add_runtime_dependency. All >> typeless >> dependencies are considered to be development dependencies. > > When I originally implemented this, typeless dependencies were > considered to be *runtime* dependencies, not development. This was to > provide backwards compatibility for older gemspecs. Did this change? Oops, fixed! From luislavena at gmail.com Tue Jun 17 16:40:05 2008 From: luislavena at gmail.com (Luis Lavena) Date: Tue, 17 Jun 2008 22:40:05 +0200 Subject: [Rubygems-developers] RubyGems 1.2.0 release in less than one week In-Reply-To: <1B53EFC3-CCA4-48DD-A496-23935BF462D4@segment7.net> References: <2bce3eb60806161800y3f8ada7bi7106d00de43ab570@mail.gmail.com> <1B53EFC3-CCA4-48DD-A496-23935BF462D4@segment7.net> Message-ID: <71166b3b0806171340p78fbbd1cqf0c0c0792e287eb2@mail.gmail.com> On Tue, Jun 17, 2008 at 8:02 PM, Eric Hodel wrote: > On Jun 16, 2008, at 18:00 PM, John Barnette wrote: >> >> On Mon, Jun 16, 2008 at 5:58 PM, Eric Hodel wrote: >>> >>> * RubyGems now has runtime and development dependency types. Use >>> #add_development_dependency and #add_runtime_dependency. All typeless >>> dependencies are considered to be development dependencies. >> >> When I originally implemented this, typeless dependencies were >> considered to be *runtime* dependencies, not development. This was to >> provide backwards compatibility for older gemspecs. Did this change? > > Oops, fixed! Oops... again: ruby 1.8.6 (2008-03-03 patchlevel 114) [i386-mswin32] 661 tests, 1863 assertions, 5 failures, 38 errors http://pastie.org/private/mq7xtkkradbmiu7lg0m3ea ruby 1.8.6 (2008-03-03 patchlevel 114) [i386-mingw32] 661 tests, 1869 assertions, 5 failures, 38 errors http://pastie.org/private/y21fdjaez9sjyaybkwaglq I'll try to take a look on friday night, since I run out of free time to do it during the week. Regards, -- Luis Lavena AREA 17 - Human beings, who are almost unique in having the ability to learn from the experience of others, are also remarkable for their apparent disinclination to do so. Douglas Adams From thewoolleyman at gmail.com Tue Jun 17 17:35:43 2008 From: thewoolleyman at gmail.com (Chad Woolley) Date: Tue, 17 Jun 2008 14:35:43 -0700 Subject: [Rubygems-developers] Problems with dependency command In-Reply-To: References: Message-ID: On Tue, Jun 17, 2008 at 1:20 AM, Eric Hodel wrote: > Fixed in r1773, but will need Tom to update the indexer code before it will > work for you. I'm still seeing failures with the dependency command in my integration tests, but I haven't had time to pinpoint yet. This is with a dependent gem that depends on a multiplatform (old-style mswin32 platform) gem. I'll try to reproduce outside of my integration tests and report back, but I believe something is still wrong in rubygems, my gems and commands still should be valid (and are against 1.1.1). -- Chad From drbrain at segment7.net Tue Jun 17 17:47:07 2008 From: drbrain at segment7.net (Eric Hodel) Date: Tue, 17 Jun 2008 14:47:07 -0700 Subject: [Rubygems-developers] RubyGems 1.2.0 release in less than one week In-Reply-To: <71166b3b0806171340p78fbbd1cqf0c0c0792e287eb2@mail.gmail.com> References: <2bce3eb60806161800y3f8ada7bi7106d00de43ab570@mail.gmail.com> <1B53EFC3-CCA4-48DD-A496-23935BF462D4@segment7.net> <71166b3b0806171340p78fbbd1cqf0c0c0792e287eb2@mail.gmail.com> Message-ID: On Jun 17, 2008, at 13:40 PM, Luis Lavena wrote: > Oops... again: > > ruby 1.8.6 (2008-03-03 patchlevel 114) [i386-mswin32] > 661 tests, 1863 assertions, 5 failures, 38 errors > 1) Error: test_execute_remote(TestGemCommandsDependencyCommand): > Errno::ENOTDIR: Not a directory - D:/Temp/test_rubygems_3880/ > userhome/.gem/specs/gems.example.com:80 : is not a valid file character on windows, I changed it to %. > 32) Failure: test_extract_files(TestGemInstaller) [./test/ > test_gem_installer.rb:133]: <256> expected but was <292>. This was a file permissions test, I wrapped it in an unless Gem.win_platform? > 43) Failure: test_initialize_expand_path(TestGemUninstaller) [./test/ > test_gem_uninstaller.rb:21]: <"/foo/bar"> expected but was <"D:/foo/ > bar">. This I replaced with an assert_match %r|/foo/bar$| as I don't think I care about the directory. > I'll try to take a look on friday night, since I run out of free time > to do it during the week. Can you try to do a test run and report the new failures (or hopefully that everything passes). From thewoolleyman at gmail.com Wed Jun 18 00:47:11 2008 From: thewoolleyman at gmail.com (Chad Woolley) Date: Tue, 17 Jun 2008 21:47:11 -0700 Subject: [Rubygems-developers] Problems with dependency command In-Reply-To: References: Message-ID: On Tue, Jun 17, 2008 at 2:35 PM, Chad Woolley wrote: > I'll try to reproduce outside of my integration tests and report back, > but I believe something is still wrong in rubygems, my gems and > commands still should be valid (and are against 1.1.1). I've got an isolated reproducible failure against my test gems. Check out spec/manualtest/gem_dependency.sh in geminstaller (start server with spec/manualtest/start_gem_server.sh) -- Chad From thewoolleyman at gmail.com Wed Jun 18 02:10:47 2008 From: thewoolleyman at gmail.com (Chad Woolley) Date: Tue, 17 Jun 2008 23:10:47 -0700 Subject: [Rubygems-developers] Problems with dependency command In-Reply-To: References: Message-ID: On Tue, Jun 17, 2008 at 9:47 PM, Chad Woolley wrote: > I've got an isolated reproducible failure against my test gems. Check > out spec/manualtest/gem_dependency.sh in geminstaller (start server > with spec/manualtest/start_gem_server.sh) I think I tracked it down to DependencyCommand#execute: When no gem name arg is passed to dependency, a regexp gets created with '.'. This won't ever match any gems. I don't think this is the cause of my original problem though, still looking into it. From luislavena at gmail.com Wed Jun 18 04:08:01 2008 From: luislavena at gmail.com (Luis Lavena) Date: Wed, 18 Jun 2008 10:08:01 +0200 Subject: [Rubygems-developers] RubyGems 1.2.0 release in less than one week In-Reply-To: References: <2bce3eb60806161800y3f8ada7bi7106d00de43ab570@mail.gmail.com> <1B53EFC3-CCA4-48DD-A496-23935BF462D4@segment7.net> <71166b3b0806171340p78fbbd1cqf0c0c0792e287eb2@mail.gmail.com> Message-ID: <71166b3b0806180108m7a684e5cm384ddbdda75b28fe@mail.gmail.com> On Tue, Jun 17, 2008 at 11:47 PM, Eric Hodel wrote: > On Jun 17, 2008, at 13:40 PM, Luis Lavena wrote: >> .. > >> I'll try to take a look on friday night, since I run out of free time >> to do it during the week. > > Can you try to do a test run and report the new failures (or hopefully that > everything passes). > Yes sir! :-) ruby 1.8.6 (2008-03-03 patchlevel 114) [i386-mswin32] 661 tests, 1938 assertions, 1 failures, 2 errors http://pastie.org/private/ynl4opd4xgjcidkzgxna ruby 1.8.6 (2008-03-03 patchlevel 114) [i386-mingw32] 661 tests, 1944 assertions, 1 failures, 2 errors http://pastie.org/private/lnmlvoney68rmy5etnnodq Just a reminder: directory or filenames in Windows cannot contain ':' as part of it (since double colons are used as drive letter separator). So the port in the spec cache is getting in our way. Can we change (gsub) using . (dot) instead? will impose other complexity? Thanks again for your time Eric. Regards, -- Luis Lavena AREA 17 - Human beings, who are almost unique in having the ability to learn from the experience of others, are also remarkable for their apparent disinclination to do so. Douglas Adams From thewoolleyman at gmail.com Wed Jun 18 04:14:06 2008 From: thewoolleyman at gmail.com (Chad Woolley) Date: Wed, 18 Jun 2008 01:14:06 -0700 Subject: [Rubygems-developers] Problems with dependency command In-Reply-To: References: Message-ID: On Tue, Jun 17, 2008 at 11:10 PM, Chad Woolley wrote: > I think I tracked it down to DependencyCommand#execute: When no gem > name arg is passed to dependency, a regexp gets created with '.'. > This won't ever match any gems. One other problem - you used to be able to pass a regexp to the dependency (and list) commands. Now, this doesn't work. However, this means there is no longer a way to do an exact gem name match like ^gemname$. Bugs opened for these: http://rubyforge.org/tracker/index.php?func=detail&aid=20716&group_id=126&atid=575 http://rubyforge.org/tracker/index.php?func=detail&aid=20717&group_id=126&atid=575 From drbrain at segment7.net Wed Jun 18 19:13:15 2008 From: drbrain at segment7.net (Eric Hodel) Date: Wed, 18 Jun 2008 16:13:15 -0700 Subject: [Rubygems-developers] RubyGems 1.2.0 release in less than one week In-Reply-To: <71166b3b0806180108m7a684e5cm384ddbdda75b28fe@mail.gmail.com> References: <2bce3eb60806161800y3f8ada7bi7106d00de43ab570@mail.gmail.com> <1B53EFC3-CCA4-48DD-A496-23935BF462D4@segment7.net> <71166b3b0806171340p78fbbd1cqf0c0c0792e287eb2@mail.gmail.com> <71166b3b0806180108m7a684e5cm384ddbdda75b28fe@mail.gmail.com> Message-ID: <3203D49E-4DF6-4B74-9AE7-7C7F284FD0F3@segment7.net> On Jun 18, 2008, at 01:08 AM, Luis Lavena wrote: > ruby 1.8.6 (2008-03-03 patchlevel 114) [i386-mswin32] > 661 tests, 1938 assertions, 1 failures, 2 errors > http://pastie.org/private/ynl4opd4xgjcidkzgxna > > ruby 1.8.6 (2008-03-03 patchlevel 114) [i386-mingw32] > 661 tests, 1944 assertions, 1 failures, 2 errors > http://pastie.org/private/lnmlvoney68rmy5etnnodq 1) Failure: test_install_dual_repository(TestGemDependencyInstaller) [./test/test_gem_dependency_installer.rb:383]: <["b-1"]> expected but was <["a-1", "b-1"]>. I'm not sure I fixed this. I committed this change: Index: test/test_gem_dependency_installer.rb =================================================================== --- test/test_gem_dependency_installer.rb (revision 1781) +++ test/test_gem_dependency_installer.rb (working copy) @@ -372,7 +372,7 @@ class TestGemDependencyInstaller < RubyG end ENV['GEM_HOME'] = @gemhome - ENV['GEM_PATH'] = [@gemhome, gemhome2].join ':' + ENV['GEM_PATH'] = [@gemhome, gemhome2].join File::PATH_SEPARATOR Gem.clear_paths Dir.chdir @tempdir do but it may not be correct. > Just a reminder: directory or filenames in Windows cannot contain ':' > as part of it (since double colons are used as drive letter > separator). So the port in the spec cache is getting in our way. Can > we change (gsub) using . (dot) instead? will impose other complexity? I chose %, is that ok? It seems to be a valid filesystem character for all platforms. From drbrain at segment7.net Wed Jun 18 20:41:44 2008 From: drbrain at segment7.net (Eric Hodel) Date: Wed, 18 Jun 2008 17:41:44 -0700 Subject: [Rubygems-developers] Problems with dependency command In-Reply-To: References: Message-ID: <3B69D069-A4F6-48F5-AE67-00BD2BC55D8F@segment7.net> On Jun 18, 2008, at 01:14 AM, Chad Woolley wrote: > On Tue, Jun 17, 2008 at 11:10 PM, Chad Woolley > wrote: >> I think I tracked it down to DependencyCommand#execute: When no gem >> name arg is passed to dependency, a regexp gets created with '.'. >> This won't ever match any gems. > > One other problem - you used to be able to pass a regexp to the > dependency (and list) commands. Now, this doesn't work. However, > this means there is no longer a way to do an exact gem name match like > ^gemname$. > > Bugs opened for these: > > http://rubyforge.org/tracker/index.php?func=detail&aid=20716&group_id=126&atid=575 > > http://rubyforge.org/tracker/index.php?func=detail&aid=20717&group_id=126&atid=575 Should all be fixed with r1787 From yaohan.chen at gmail.com Wed Jun 18 23:59:59 2008 From: yaohan.chen at gmail.com (Yaohan Chen) Date: Wed, 18 Jun 2008 23:59:59 -0400 Subject: [Rubygems-developers] Gem::Ext::RakeBuilder ignores custom Rakefile name Message-ID: <200806190000.04932.yaohan.chen@gmail.com> Hi, I'm working on a project which compiles and uses some platform dependent files, but they are not built from C files. The method to generate those files is already in the project's Rakefile as a task, so I wanted to use gem's Rakefile extension builder. I have spec.extensions << "Rakefile.ext" But the extension building phase fails saying Rakefile cannot be found. Looking lib/rubygems/ext/rake_builder.rb lines 11-21, def self.build(extension, directory, dest_path, results) if File.basename(extension) =~ /mkrf_conf/i then cmd = "#{Gem.ruby} #{File.basename extension}" cmd << " #{ARGV.join " "}" unless ARGV.empty? run cmd, results end cmd = ENV['rake'] || 'rake' cmd << " RUBYARCHDIR=#{dest_path} RUBYLIBDIR=#{dest_path} run cmd, results It seems that if the Rakefile contains mkrf_conf in the basename (btw I see some mkrf_conf.rb files on the web, but none with both Rakefile and mkmf_conf in its name) then it is treated as a "configure script", it is executed and afterwards a Rakefile is expected to be created. Otherwise, the file must be named Rakefile. If this is by design, there is a usability problem in accepting any filename containing Rakefile in spec.extensions. There is also a problem with requiring the file to be called Rakefile. The project already has a Rakefile containing various tasks such as gem, and a task for building the extension. It doesn't make sense to have the default rule build the extension, which is why I am trying to use a different Rakefile. But if it's possible to name the task to execute, along with the Rakefile in specification.extensions, I would have no problem. Finally, is the Rakefile expected to both build and install the extensions in its default task? Thank you in advance. Yaohan Chen From yaohan.chen at gmail.com Thu Jun 19 00:04:41 2008 From: yaohan.chen at gmail.com (Yaohan Chen) Date: Thu, 19 Jun 2008 00:04:41 -0400 Subject: [Rubygems-developers] Gem::Ext::RakeBuilder ignores custom Rakefile name In-Reply-To: <200806190000.04932.yaohan.chen@gmail.com> References: <200806190000.04932.yaohan.chen@gmail.com> Message-ID: <200806190004.41680.yaohan.chen@gmail.com> Sorry, please ignore what I wrote about both Rakefile and mkrf_conf in the filename, I just noticed that the RakeBuilder is invoked when the filename contains *either* Rakefile or mkrf_conf. Yaohan Chen On Wednesday 18 June 2008 11:59:59 pm Yaohan Chen wrote: > Hi, > > I'm working on a project which compiles and uses some platform dependent > files, but they are not built from C files. The method to generate those > files is already in the project's Rakefile as a task, so I wanted to use > gem's Rakefile extension builder. I have > > spec.extensions << "Rakefile.ext" > > But the extension building phase fails saying Rakefile cannot be found. > Looking lib/rubygems/ext/rake_builder.rb lines 11-21, > > def self.build(extension, directory, dest_path, results) > if File.basename(extension) =~ /mkrf_conf/i then > cmd = "#{Gem.ruby} #{File.basename extension}" > cmd << " #{ARGV.join " "}" unless ARGV.empty? > run cmd, results > end > > cmd = ENV['rake'] || 'rake' > cmd << " RUBYARCHDIR=#{dest_path} RUBYLIBDIR=#{dest_path} > > run cmd, results > > It seems that if the Rakefile contains mkrf_conf in the basename (btw I see > some mkrf_conf.rb files on the web, but none with both Rakefile and > mkmf_conf in its name) then it is treated as a "configure script", it is > executed and afterwards a Rakefile is expected to be created. Otherwise, > the file must be named Rakefile. If this is by design, there is a usability > problem in accepting any filename containing Rakefile in spec.extensions. > > There is also a problem with requiring the file to be called Rakefile. The > project already has a Rakefile containing various tasks such as gem, and a > task for building the extension. It doesn't make sense to have the default > rule build the extension, which is why I am trying to use a different > Rakefile. But if it's possible to name the task to execute, along with the > Rakefile in specification.extensions, I would have no problem. > > Finally, is the Rakefile expected to both build and install the extensions > in its default task? > > Thank you in advance. > > > Yaohan Chen From thewoolleyman at gmail.com Thu Jun 19 01:44:57 2008 From: thewoolleyman at gmail.com (Chad Woolley) Date: Wed, 18 Jun 2008 22:44:57 -0700 Subject: [Rubygems-developers] one more dependency problem Message-ID: I'm seeing one (last?) dependency problem in trunk. I have a three-level dependency chain of test gems, and the bottom dependency is not getting installed. I can't reproduce this yet outside of my test suite (sound familiar?), so it may be a caching problem. More info later.... Failing test is GemInstaller's spec/functional/install_processor_spec.rb -- Chad From sakaia at jp.fujitsu.com Thu Jun 19 03:36:54 2008 From: sakaia at jp.fujitsu.com (Atsushi SAKAI) Date: Thu, 19 Jun 2008 16:36:54 +0900 Subject: [Rubygems-developers] About rake on MinGW w/ ruby-libvirt Message-ID: <200806190736.m5J7atG9030044@fjmscan501.ms.jp.fujitsu.com> Hi, I am trying to make ruby bindings for libvirt on MinGW. But it failed on # rake build The command "rake build" itself succeeds on Linux(fedora 6) but failed on MinGW. If you know the idea to solve this, Please suggest me. ==Environment== MinGW-5.1.4.exe (for more detail see: https://www.redhat.com/archives/libvir-list/2008-June/msg00201.html) ruby(1.8.4), rubygems(1.1.0), rake(0.8.1) seems installed successfully. ==Error== if i try to "rake build" for ruby-libvirt(http://libvirt.org/ruby/). It fails like follows. The message says "mkmf.log" should be checked. But it does not generated yet. ===============error message================ $ rake build --trace (in C:/msys/1.0/home/Administrator/work/ruby-libvirt) ** Invoke build (first_time) ** Invoke ext/libvirt/_libvirt.so (first_time) ** Invoke ext/libvirt/Makefile (first_time) ** Invoke ext/libvirt/extconf.rb (first_time, not_needed) ** Execute ext/libvirt/Makefile ruby extconf.rb *** extconf.rb failed *** Could not create Makefile due to some reason, probably lack of necessary libraries and/or headers. Check the mkmf.log file for more details. You may need configuration options. Provided configuration options: --with-opt-dir --with-opt-include --without-opt-include=${opt-dir}/include --with-opt-lib --without-opt-lib=${opt-dir}/lib --with-make-prog --without-make-prog --srcdir=. --curdir --ruby=C:/msys/1.0/local/bin/ruby --with-_libvirt-dir --without-_libvirt-dir --with-_libvirt-include --without-_libvirt-include=${_libvirt-dir}/include --with-_libvirt-lib --without-_libvirt-lib=${_libvirt-dir}/lib --with-pkg-config --without-pkg-config rake aborted! Command failed with status (1): [ruby extconf.rb...] C:/msys/1.0/local/lib/ruby/gems/1.8/gems/rake-0.8.1/lib/rake.rb:899:in `sh' C:/msys/1.0/local/lib/ruby/gems/1.8/gems/rake-0.8.1/lib/rake.rb:906:in `sh' C:/msys/1.0/local/lib/ruby/gems/1.8/gems/rake-0.8.1/lib/rake.rb:985:in `sh' C:/msys/1.0/local/lib/ruby/gems/1.8/gems/rake-0.8.1/lib/rake.rb:980:in `sh' C:/msys/1.0/home/Administrator/work/ruby-libvirt/rakefile:43 C:/msys/1.0/home/Administrator/work/ruby-libvirt/rakefile:42 C:/msys/1.0/local/lib/ruby/gems/1.8/gems/rake-0.8.1/lib/rake.rb:544:in `execute' C:/msys/1.0/local/lib/ruby/gems/1.8/gems/rake-0.8.1/lib/rake.rb:541:in `execute' C:/msys/1.0/local/lib/ruby/gems/1.8/gems/rake-0.8.1/lib/rake.rb:508:in `invoke_with_call_chain' C:/msys/1.0/local/lib/ruby/1.8/thread.rb:135:in `synchronize' C:/msys/1.0/local/lib/ruby/gems/1.8/gems/rake-0.8.1/lib/rake.rb:501:in `invoke_with_call_chain' C:/msys/1.0/local/lib/ruby/gems/1.8/gems/rake-0.8.1/lib/rake.rb:518:in `invoke_prerequisites' C:/msys/1.0/local/lib/ruby/gems/1.8/gems/rake-0.8.1/lib/rake.rb:1183:in `each' C:/msys/1.0/local/lib/ruby/gems/1.8/gems/rake-0.8.1/lib/rake.rb:515:in `invoke_prerequisites' C:/msys/1.0/local/lib/ruby/gems/1.8/gems/rake-0.8.1/lib/rake.rb:507:in `invoke_with_call_chain' C:/msys/1.0/local/lib/ruby/1.8/thread.rb:135:in `synchronize' C:/msys/1.0/local/lib/ruby/gems/1.8/gems/rake-0.8.1/lib/rake.rb:501:in `invoke_with_call_chain' C:/msys/1.0/local/lib/ruby/gems/1.8/gems/rake-0.8.1/lib/rake.rb:518:in `invoke_prerequisites' C:/msys/1.0/local/lib/ruby/gems/1.8/gems/rake-0.8.1/lib/rake.rb:1183:in `each' C:/msys/1.0/local/lib/ruby/gems/1.8/gems/rake-0.8.1/lib/rake.rb:515:in `invoke_prerequisites' C:/msys/1.0/local/lib/ruby/gems/1.8/gems/rake-0.8.1/lib/rake.rb:507:in `invoke_with_call_chain' C:/msys/1.0/local/lib/ruby/1.8/thread.rb:135:in `synchronize' C:/msys/1.0/local/lib/ruby/gems/1.8/gems/rake-0.8.1/lib/rake.rb:501:in `invoke_with_call_chain' C:/msys/1.0/local/lib/ruby/gems/1.8/gems/rake-0.8.1/lib/rake.rb:494:in `invoke' C:/msys/1.0/local/lib/ruby/gems/1.8/gems/rake-0.8.1/lib/rake.rb:1931:in `invoke_task' C:/msys/1.0/local/lib/ruby/gems/1.8/gems/rake-0.8.1/lib/rake.rb:1909:in `top_level' C:/msys/1.0/local/lib/ruby/gems/1.8/gems/rake-0.8.1/lib/rake.rb:1909:in `top_level' C:/msys/1.0/local/lib/ruby/gems/1.8/gems/rake-0.8.1/lib/rake.rb:1948:in `standard_exception_handling' C:/msys/1.0/local/lib/ruby/gems/1.8/gems/rake-0.8.1/lib/rake.rb:1903:in `top_level' C:/msys/1.0/local/lib/ruby/gems/1.8/gems/rake-0.8.1/lib/rake.rb:1881:in `run' C:/msys/1.0/local/lib/ruby/gems/1.8/gems/rake-0.8.1/lib/rake.rb:1948:in `standard_exception_handling' C:/msys/1.0/local/lib/ruby/gems/1.8/gems/rake-0.8.1/lib/rake.rb:1878:in `run' C:/msys/1.0/local/lib/ruby/gems/1.8/gems/rake-0.8.1/bin/rake:31 C:/msys/1.0/local/bin/rake:19 ======================================== Thanks Atsushi SAKAI From luislavena at gmail.com Thu Jun 19 04:36:44 2008 From: luislavena at gmail.com (Luis Lavena) Date: Thu, 19 Jun 2008 10:36:44 +0200 Subject: [Rubygems-developers] About rake on MinGW w/ ruby-libvirt In-Reply-To: <200806190736.m5J7atG9030044@fjmscan501.ms.jp.fujitsu.com> References: <200806190736.m5J7atG9030044@fjmscan501.ms.jp.fujitsu.com> Message-ID: <71166b3b0806190136v3291bab7w967f12d3e976bafb@mail.gmail.com> On Thu, Jun 19, 2008 at 9:36 AM, Atsushi SAKAI wrote: > Hi, > > I am trying to make ruby bindings for libvirt on MinGW. > But it failed on > # rake build > The command "rake build" itself succeeds on Linux(fedora 6) but failed on MinGW. > > If you know the idea to solve this, > Please suggest me. Are you trying to build with MinGW using One-Click Installer ruby? or are you trying with the MinGW version of Ruby distro I've created? Since you didn't post the output of mkmf.log file (the one that extconf.rb generates) we cannot figure out what is actually happening, but I guess is the VC6 vs. MinGW issue. You can grab a "pre-baked" mingw+msys environment for ruby here: http://dump.mmediasys.com/installer3 And also a MinGW compiled ruby there (1.8.6-p114) > ==Environment== > MinGW-5.1.4.exe > (for more detail see: https://www.redhat.com/archives/libvir-list/2008-June/msg00201.html) > ruby(1.8.4), rubygems(1.1.0), rake(0.8.1) seems installed successfully. I suggest you try build libvirt first using the MinGW provided (add the missing pieces from the environment you described before build the ruby-libvirt bindings. You can join us at rubyinstaller-devel mailing list: http://rubyforge.org/mailman/listinfo/rubyinstaller-devel Since we are working on improve stability of MinGW for Ruby and the extensions around it. Hope that helps, -- Luis Lavena AREA 17 - Human beings, who are almost unique in having the ability to learn from the experience of others, are also remarkable for their apparent disinclination to do so. Douglas Adams From sakaia at jp.fujitsu.com Thu Jun 19 04:54:39 2008 From: sakaia at jp.fujitsu.com (Atsushi SAKAI) Date: Thu, 19 Jun 2008 17:54:39 +0900 Subject: [Rubygems-developers] About rake on MinGW w/ ruby-libvirt In-Reply-To: <71166b3b0806190136v3291bab7w967f12d3e976bafb@mail.gmail.com> References: <71166b3b0806190136v3291bab7w967f12d3e976bafb@mail.gmail.com> Message-ID: <200806190854.m5J8seKi018846@fjmscan501.ms.jp.fujitsu.com> Thank you I am just building ruby on MinGW. with ruby http://ftp.ruby-lang.org/pub/ruby/binaries/mingw/1.8/ with rubygems 1.1.0 http://rubyforge.org/frs/?group_id=126 and rake is taken by ruby install rake --remote (0.8.1) and mkmf.log cannot taken from my environment. Thanks Atsushi SAKAI "Luis Lavena" wrote: > On Thu, Jun 19, 2008 at 9:36 AM, Atsushi SAKAI wrote: > > Hi, > > > > I am trying to make ruby bindings for libvirt on MinGW. > > But it failed on > > # rake build > > The command "rake build" itself succeeds on Linux(fedora 6) but failed on MinGW. > > > > If you know the idea to solve this, > > Please suggest me. > > Are you trying to build with MinGW using One-Click Installer ruby? or > are you trying with the MinGW version of Ruby distro I've created? > > Since you didn't post the output of mkmf.log file (the one that > extconf.rb generates) we cannot figure out what is actually happening, > but I guess is the VC6 vs. MinGW issue. > > You can grab a "pre-baked" mingw+msys environment for ruby here: > > http://dump.mmediasys.com/installer3 > > And also a MinGW compiled ruby there (1.8.6-p114) > > > ==Environment== > > MinGW-5.1.4.exe > > (for more detail see: https://www.redhat.com/archives/libvir-list/2008-June/msg00201.html) > > ruby(1.8.4), rubygems(1.1.0), rake(0.8.1) seems installed successfully. > > I suggest you try build libvirt first using the MinGW provided (add > the missing pieces from the environment you described before build the > ruby-libvirt bindings. > > You can join us at rubyinstaller-devel mailing list: > > http://rubyforge.org/mailman/listinfo/rubyinstaller-devel > > Since we are working on improve stability of MinGW for Ruby and the > extensions around it. > > Hope that helps, > -- > Luis Lavena > AREA 17 > - > Human beings, who are almost unique in having the ability to learn from > the experience of others, are also remarkable for their apparent > disinclination to do so. > Douglas Adams > _______________________________________________ > Rubygems-developers mailing list > Rubygems-developers at rubyforge.org > http://rubyforge.org/mailman/listinfo/rubygems-developers From luislavena at gmail.com Thu Jun 19 05:00:27 2008 From: luislavena at gmail.com (Luis Lavena) Date: Thu, 19 Jun 2008 11:00:27 +0200 Subject: [Rubygems-developers] RubyGems 1.2.0 release in less than one week In-Reply-To: <3203D49E-4DF6-4B74-9AE7-7C7F284FD0F3@segment7.net> References: <2bce3eb60806161800y3f8ada7bi7106d00de43ab570@mail.gmail.com> <1B53EFC3-CCA4-48DD-A496-23935BF462D4@segment7.net> <71166b3b0806171340p78fbbd1cqf0c0c0792e287eb2@mail.gmail.com> <71166b3b0806180108m7a684e5cm384ddbdda75b28fe@mail.gmail.com> <3203D49E-4DF6-4B74-9AE7-7C7F284FD0F3@segment7.net> Message-ID: <71166b3b0806190200p12e49536r4e9891b3febd115f@mail.gmail.com> On Thu, Jun 19, 2008 at 1:13 AM, Eric Hodel wrote: > On Jun 18, 2008, at 01:08 AM, Luis Lavena wrote: >> >> ruby 1.8.6 (2008-03-03 patchlevel 114) [i386-mswin32] >> 661 tests, 1938 assertions, 1 failures, 2 errors >> http://pastie.org/private/ynl4opd4xgjcidkzgxna >> >> ruby 1.8.6 (2008-03-03 patchlevel 114) [i386-mingw32] >> 661 tests, 1944 assertions, 1 failures, 2 errors >> http://pastie.org/private/lnmlvoney68rmy5etnnodq > > 1) Failure: test_install_dual_repository(TestGemDependencyInstaller) > [./test/test_gem_dependency_installer.rb:383]: > <["b-1"]> expected but was > <["a-1", "b-1"]>. > > I'm not sure I fixed this. I committed this change: > > Index: test/test_gem_dependency_installer.rb > =================================================================== > --- test/test_gem_dependency_installer.rb (revision 1781) > +++ test/test_gem_dependency_installer.rb (working copy) > @@ -372,7 +372,7 @@ class TestGemDependencyInstaller < RubyG > end > > ENV['GEM_HOME'] = @gemhome > - ENV['GEM_PATH'] = [@gemhome, gemhome2].join ':' > + ENV['GEM_PATH'] = [@gemhome, gemhome2].join File::PATH_SEPARATOR > Gem.clear_paths > > Dir.chdir @tempdir do > > > but it may not be correct. > Actually, is correct, if you're joining two paths must always use the platform implementation. If you're joining a directory structure to a file, you must always use File.join or join with File::SEPARATOR, just to be sure that will work across platforms. >> Just a reminder: directory or filenames in Windows cannot contain ':' >> as part of it (since double colons are used as drive letter >> separator). So the port in the spec cache is getting in our way. Can >> we change (gsub) using . (dot) instead? will impose other complexity? > > I chose %, is that ok? It seems to be a valid filesystem character for all > platforms. Yes, it's great! %, used from the command line (the console) must be quoted since can be interpreted as batch command, but called from programs is ok. ruby 1.8.6 (2008-03-03 patchlevel 114) [i386-mswin32] 664 tests, 1948 assertions, 0 failures, 0 errors ruby 1.8.6 (2008-03-03 patchlevel 114) [i386-mingw32] 664 tests, 1954 assertions, 0 failures, 0 errors I think we only need GemInstaller regression tests to get pass and we are good to go. I'll check during weekend the functionality on Windows. Looks like we are ok now :-) -- Luis Lavena AREA 17 - Human beings, who are almost unique in having the ability to learn from the experience of others, are also remarkable for their apparent disinclination to do so. Douglas Adams From luislavena at gmail.com Thu Jun 19 05:02:11 2008 From: luislavena at gmail.com (Luis Lavena) Date: Thu, 19 Jun 2008 11:02:11 +0200 Subject: [Rubygems-developers] About rake on MinGW w/ ruby-libvirt In-Reply-To: <200806190854.m5J8seKi018846@fjmscan501.ms.jp.fujitsu.com> References: <71166b3b0806190136v3291bab7w967f12d3e976bafb@mail.gmail.com> <200806190854.m5J8seKi018846@fjmscan501.ms.jp.fujitsu.com> Message-ID: <71166b3b0806190202k6f7bed74v13fd62c91cdb224c@mail.gmail.com> On Thu, Jun 19, 2008 at 10:54 AM, Atsushi SAKAI wrote: > > > Thank you > > I am just building ruby on MinGW. > with ruby > http://ftp.ruby-lang.org/pub/ruby/binaries/mingw/1.8/ > with rubygems 1.1.0 > http://rubyforge.org/frs/?group_id=126 > and rake is taken by ruby install rake --remote (0.8.1) > > and mkmf.log cannot taken from my environment. > then extconf.rb must be reviewed since mkmf.log is where the compiler supposed to dump tests of libraries and headers. Regards, -- Luis Lavena AREA 17 - Human beings, who are almost unique in having the ability to learn from the experience of others, are also remarkable for their apparent disinclination to do so. Douglas Adams From thewoolleyman at gmail.com Thu Jun 19 10:24:31 2008 From: thewoolleyman at gmail.com (Chad Woolley) Date: Thu, 19 Jun 2008 07:24:31 -0700 Subject: [Rubygems-developers] RubyGems 1.2.0 release in less than one week In-Reply-To: <71166b3b0806190200p12e49536r4e9891b3febd115f@mail.gmail.com> References: <2bce3eb60806161800y3f8ada7bi7106d00de43ab570@mail.gmail.com> <1B53EFC3-CCA4-48DD-A496-23935BF462D4@segment7.net> <71166b3b0806171340p78fbbd1cqf0c0c0792e287eb2@mail.gmail.com> <71166b3b0806180108m7a684e5cm384ddbdda75b28fe@mail.gmail.com> <3203D49E-4DF6-4B74-9AE7-7C7F284FD0F3@segment7.net> <71166b3b0806190200p12e49536r4e9891b3febd115f@mail.gmail.com> Message-ID: On Thu, Jun 19, 2008 at 2:00 AM, Luis Lavena wrote: > I think we only need GemInstaller regression tests to get pass and we > are good to go. I'll check during weekend the functionality on > Windows. It is the multilevel dependency one that is failing (install_processor), as mentioned on the separate thread. I tried to narrow it down last night, but failed (ruby-debug still fails in rubygems a lot of the time due to rdoc/ri conflicts). From drbrain at segment7.net Thu Jun 19 18:10:03 2008 From: drbrain at segment7.net (Eric Hodel) Date: Thu, 19 Jun 2008 15:10:03 -0700 Subject: [Rubygems-developers] RubyGems 1.2.0 release in less than one week In-Reply-To: <71166b3b0806190200p12e49536r4e9891b3febd115f@mail.gmail.com> References: <2bce3eb60806161800y3f8ada7bi7106d00de43ab570@mail.gmail.com> <1B53EFC3-CCA4-48DD-A496-23935BF462D4@segment7.net> <71166b3b0806171340p78fbbd1cqf0c0c0792e287eb2@mail.gmail.com> <71166b3b0806180108m7a684e5cm384ddbdda75b28fe@mail.gmail.com> <3203D49E-4DF6-4B74-9AE7-7C7F284FD0F3@segment7.net> <71166b3b0806190200p12e49536r4e9891b3febd115f@mail.gmail.com> Message-ID: <5CAF1F65-A673-4176-99F2-8A0749C07B21@segment7.net> On Jun 19, 2008, at 02:00 AM, Luis Lavena wrote: >> I'm not sure I fixed this. I committed this change: >> >> [...] >> >> but it may not be correct. > > Actually, is correct, if you're joining two paths must always use the > platform implementation. If you're joining a directory structure to a > file, you must always use File.join or join with File::SEPARATOR, just > to be sure that will work across platforms. I wasn't sure if it would actually fix it :) I'm glad it did. From drbrain at segment7.net Thu Jun 19 19:22:16 2008 From: drbrain at segment7.net (Eric Hodel) Date: Thu, 19 Jun 2008 16:22:16 -0700 Subject: [Rubygems-developers] RubyGems 1.2.0 release in less than one week In-Reply-To: References: <2bce3eb60806161800y3f8ada7bi7106d00de43ab570@mail.gmail.com> <1B53EFC3-CCA4-48DD-A496-23935BF462D4@segment7.net> <71166b3b0806171340p78fbbd1cqf0c0c0792e287eb2@mail.gmail.com> <71166b3b0806180108m7a684e5cm384ddbdda75b28fe@mail.gmail.com> <3203D49E-4DF6-4B74-9AE7-7C7F284FD0F3@segment7.net> <71166b3b0806190200p12e49536r4e9891b3febd115f@mail.gmail.com> Message-ID: On Jun 19, 2008, at 07:24 AM, Chad Woolley wrote: > On Thu, Jun 19, 2008 at 2:00 AM, Luis Lavena > wrote: >> I think we only need GemInstaller regression tests to get pass and we >> are good to go. I'll check during weekend the functionality on >> Windows. > > It is the multilevel dependency one that is failing > (install_processor), as mentioned on the separate thread. I tried to > narrow it down last night, but failed (ruby-debug still fails in > rubygems a lot of the time due to rdoc/ri conflicts). Ok, seems fixed with 1785. Any other issues? If no more are reported by Friday night Pacific Time, I will release Saturday afternoon Pacific Time. From mkent at magoazul.com Thu Jun 19 19:43:47 2008 From: mkent at magoazul.com (Matthew Kent) Date: Thu, 19 Jun 2008 16:43:47 -0700 (PDT) Subject: [Rubygems-developers] RubyGems 1.2.0 release in less than one week In-Reply-To: References: <2bce3eb60806161800y3f8ada7bi7106d00de43ab570@mail.gmail.com> <1B53EFC3-CCA4-48DD-A496-23935BF462D4@segment7.net> <71166b3b0806171340p78fbbd1cqf0c0c0792e287eb2@mail.gmail.com> <71166b3b0806180108m7a684e5cm384ddbdda75b28fe@mail.gmail.com> <3203D49E-4DF6-4B74-9AE7-7C7F284FD0F3@segment7.net> <71166b3b0806190200p12e49536r4e9891b3febd115f@mail.gmail.com> Message-ID: <47568.142.179.103.34.1213919027.squirrel@mail.voxel.net> > On Jun 19, 2008, at 07:24 AM, Chad Woolley wrote: >> On Thu, Jun 19, 2008 at 2:00 AM, Luis Lavena >> wrote: >>> I think we only need GemInstaller regression tests to get pass and we >>> are good to go. I'll check during weekend the functionality on >>> Windows. >> >> It is the multilevel dependency one that is failing >> (install_processor), as mentioned on the separate thread. I tried to >> narrow it down last night, but failed (ruby-debug still fails in >> rubygems a lot of the time due to rdoc/ri conflicts). > > Ok, seems fixed with 1785. > > Any other issues? > Hi guys :) I tossed a bug up http://rubyforge.org/tracker/index.php?func=detail&aid=20744&group_id=3780&atid=14602 that if solved may help people better package the new release. Thanks for the great software. -- Matthew Kent http://magoazul.com From thewoolleyman at gmail.com Thu Jun 19 21:21:53 2008 From: thewoolleyman at gmail.com (Chad Woolley) Date: Thu, 19 Jun 2008 18:21:53 -0700 Subject: [Rubygems-developers] Incrementing Gem::RubyGemsVersion on trunk? In-Reply-To: <470C9550-5346-4C7C-90CD-EA8AA51CB2BC@zenspider.com> References: <470C9550-5346-4C7C-90CD-EA8AA51CB2BC@zenspider.com> Message-ID: On Fri, Mar 28, 2008 at 2:07 PM, Ryan Davis wrote: > On Mar 27, 2008, at 22:02 , Chad Woolley wrote: >> RubyGemsVersion = '1.0.1' + (ENV['TRUNK_VERSION'] ? '.' + `svn log -q >> -rhead http://rubygems.rubyforge.org/svn/trunk`.scan(/ >> r([0-9]*)/).first.first.to_s >> : "") > > `svnversion .`.chomp Bringing this thread back to life. Currently, I can't get a green build against trunk for this reason, because I have a >= 1.2.0 check for code that deals with parsing the dependency output, which now includes the dependency type. I'm currently manually updating the version in my local dev and CI copies, but that's just dumb. So, I'd like to append the output of `svnversion .`.chomp to Gem::RubyGemsVersion, if (and only if) an environment variable is set. 'USE_SVNVERSION' unless someone has a better idea. Any objections? Thanks, -- Chad From thewoolleyman at gmail.com Thu Jun 19 22:00:48 2008 From: thewoolleyman at gmail.com (Chad Woolley) Date: Thu, 19 Jun 2008 19:00:48 -0700 Subject: [Rubygems-developers] One remaining dependency-related failure on Windows Message-ID: My regression tests are green on Mac and Linux (other than the hoe trailing-slash error I showed you, Eric) There is one test failing on Windows. Haven't looked into it: 1) 'The geminstaller command line application should handle a multiplatform dependency chain' FAILED expected: true, got: false (using ==) spec/functional/geminstaller_spec.rb:138: spec/functional/geminstaller_spec.rb:267: Finished in 14.434 seconds 16 examples, 1 failure From thewoolleyman at gmail.com Thu Jun 19 22:19:25 2008 From: thewoolleyman at gmail.com (Chad Woolley) Date: Thu, 19 Jun 2008 19:19:25 -0700 Subject: [Rubygems-developers] Trailing dash bug Message-ID: I have a reproducible error in my integration smoke tests where hoe fails to install when it is part of a heckle -> hoe -> rubyforge dependency chain. You can see the failure by running 'rake install_smoketest' in geminstaller. Strangely, this is not in my unit or functional tests, but they all run in the interpreter, whereas my smoke tests are run via the command line. The cause is a trailing dash (hoe-) getting appended somewhere, as I've discussed with Eric. I don't think this occurred in 1.1.1 Bug here: http://rubyforge.org/tracker/index.php?func=detail&aid=20746&group_id=126&atid=575 Thanks, -- Chad From drbrain at segment7.net Fri Jun 20 03:33:57 2008 From: drbrain at segment7.net (Eric Hodel) Date: Fri, 20 Jun 2008 00:33:57 -0700 Subject: [Rubygems-developers] RubyGems 1.2.0 release in less than one week In-Reply-To: <47568.142.179.103.34.1213919027.squirrel@mail.voxel.net> References: <2bce3eb60806161800y3f8ada7bi7106d00de43ab570@mail.gmail.com> <1B53EFC3-CCA4-48DD-A496-23935BF462D4@segment7.net> <71166b3b0806171340p78fbbd1cqf0c0c0792e287eb2@mail.gmail.com> <71166b3b0806180108m7a684e5cm384ddbdda75b28fe@mail.gmail.com> <3203D49E-4DF6-4B74-9AE7-7C7F284FD0F3@segment7.net> <71166b3b0806190200p12e49536r4e9891b3febd115f@mail.gmail.com> <47568.142.179.103.34.1213919027.squirrel@mail.voxel.net> Message-ID: On Jun 19, 2008, at 16:43 PM, Matthew Kent wrote: > Hi guys :) > > I tossed a bug up > http://rubyforge.org/tracker/index.php?func=detail&aid=20744&group_id=3780&atid=14602 > that if solved may help people better package the new release. > > Thanks for the great software. You'll probably want to email David directly to make sure he sees it. I don't know if he reads this list. From drbrain at segment7.net Sat Jun 21 23:32:10 2008 From: drbrain at segment7.net (Eric Hodel) Date: Sat, 21 Jun 2008 20:32:10 -0700 Subject: [Rubygems-developers] [ANN] RubyGems 1.2.0 Message-ID: <10510648-3697-4E69-9906-BEDCB88C1A35@segment7.net> = Announce: RubyGems Release 1.2.0 Release 1.2.0 adds new features and fixes some bugs. New features: * RubyGems no longer performs bulk updates and instead only fetches the gemspec files it needs. Alternate sources will need to upgrade to RubyGems 1.2 to allow RubyGems to take advantage of the new metadata updater. If a pre 1.2 remote source is in the sources list, RubyGems will revert to the bulk update code for compatibility. * RubyGems now has runtime and development dependency types. Use #add_development_dependency and #add_runtime_dependency. All typeless dependencies are considered to be runtime dependencies. * RubyGems will now require rubygems/defaults/operating_system.rb and rubygems/defaults/#{RBX_ENGINE}.rb if they exist. This allows packagers and ruby implementers to add custom behavior to RubyGems via these files. (If the RubyGems API is insufficient, please suggest improvements via the RubyGems list.) * /etc/gemrc (and windows equivalent) for global settings * setup.rb now handles --vendor and --destdir for packagers * `gem stale` command that lists gems by last access time Bugs Fixed: * File modes from gems are now honored, patch #19737 * Marshal Gem::Specification objects from the future can now be loaded. * A trailing / is now added to remote sources when missing, bug #20134 * Gems with legacy platforms will now be correctly uninstalled, patch #19877 * `gem install --no-wrappers` followed by `gem install --wrappers` no longer overwrites executables * `gem pristine` now forces reinstallation of gems, bug #20387 * RubyGems gracefully handles ^C while loading .gemspec files from disk, bug #20523 * Paths are expanded in more places, bug #19317, bug #19896 * Gem::DependencyInstaller resets installed gems every install, bug #19444 * Gem.default_path is now honored if GEM_PATH is not set, patch #19502 Other Changes Include: * setup.rb * stub files created by RubyGems 0.7.x and older are no longer removed. When upgrading from these ancient versions, upgrade to 1.1.x first to clean up stubs. * RDoc is no longer required until necessary, patch #20414 * `gem server` * Now completely matches the output of `gem generate_index` and has correct content types * Refreshes from source directories for every hit. The server will no longer need to be restarted after installing gems. * `gem query --details` and friends now display author, homepage, rubyforge url and installed location * `gem install` without -i no longer reinstalls dependencies if they are in GEM_PATH but not in GEM_HOME * Gem::RemoteFetcher now performs persistent connections for HEAD requests, bug #7973 For a full list of changes to RubyGems and the contributor for each change, see the ChangeLog file. Special thanks to Chad Wooley for backwards compatibility testing and Luis Lavena for continuing windows support. == How can I get RubyGems? NOTE: If you have installed RubyGems using a package system you may want to install a new RubyGems through the same packaging system. If you have a recent version of RubyGems (0.8.5 or later), then all you need to do is: $ gem update --system (you might need to be admin/root) (Note: You may have to run the command twice if you have any previosly installed rubygems-update gems). If you have an older version of RubyGems installed, then you can still do it in two steps: $ gem install rubygems-update (again, might need to be admin/root) $ update_rubygems (... here too) If you don't have any gems install, there is still the pre-gem approach to getting software ... doing it manually: 1. DOWNLOAD FROM: http://rubyforge.org/frs/?group_id=126 2. UNPACK INTO A DIRECTORY AND CD THERE 3. INSTALL WITH: ruby setup.rb (you may need admin/root privilege) == To File Bugs The RubyGems bug tracker can be found on RubyForge at: http://rubyforge.org/tracker/?func=add&group_id=126&atid=575 When filing a bug, `gem env` output will be helpful in diagnosing the issue. If you find a bug where RubyGems crashes, please provide debug output. You can do that with `gem --debug the_command`. == Thanks Keep those gems coming! -- Jim & Chad & Eric (for the RubyGems team) From vsizikov at gmail.com Sun Jun 22 08:25:40 2008 From: vsizikov at gmail.com (Vladimir Sizikov) Date: Sun, 22 Jun 2008 14:25:40 +0200 Subject: [Rubygems-developers] [ANN] RubyGems 1.2.0 In-Reply-To: <10510648-3697-4E69-9906-BEDCB88C1A35@segment7.net> References: <10510648-3697-4E69-9906-BEDCB88C1A35@segment7.net> Message-ID: <3454c9680806220525j591ede8aj521ac35197101734@mail.gmail.com> Hi Eric, Great news! And there's the hope that the new RubyGems will be more memory efficient. I'm going to integrate the latest bits into JRuby proper soon, and we'll see. (we've been getting the constant questions from JRuby users about very high memory consumption when running rubygems). A couple of question though: On Sun, Jun 22, 2008 at 5:32 AM, Eric Hodel wrote: > * RubyGems no longer performs bulk updates and instead only fetches the > gemspec > files it needs. I'd like to double-check that the main/standard rubygems repository is already updated to take advantage of this new feature? > * RubyGems will now require rubygems/defaults/operating_system.rb and > rubygems/defaults/#{RBX_ENGINE}.rb if they exist. I think that you meant RUBY_ENGINE, not RBX_ENGINGE, right? Thanks, --Vladimir From drbrain at segment7.net Sun Jun 22 13:43:11 2008 From: drbrain at segment7.net (Eric Hodel) Date: Sun, 22 Jun 2008 10:43:11 -0700 Subject: [Rubygems-developers] [ANN] RubyGems 1.2.0 In-Reply-To: <3454c9680806220525j591ede8aj521ac35197101734@mail.gmail.com> References: <10510648-3697-4E69-9906-BEDCB88C1A35@segment7.net> <3454c9680806220525j591ede8aj521ac35197101734@mail.gmail.com> Message-ID: <469C51D1-09AB-4C62-A6BF-3315B8284346@segment7.net> On Jun 22, 2008, at 05:25 AM, Vladimir Sizikov wrote: > Great news! And there's the hope that the new RubyGems will be more > memory > efficient. I'm going to integrate the latest bits into JRuby proper > soon, and we'll see. > (we've been getting the constant questions from JRuby users about > very high > memory consumption when running rubygems). I think so. > A couple of question though: > > On Sun, Jun 22, 2008 at 5:32 AM, Eric Hodel > wrote: >> * RubyGems no longer performs bulk updates and instead only fetches >> the >> gemspec >> files it needs. > > I'd like to double-check that the main/standard rubygems repository > is already > updated to take advantage of this new feature? It has, as has at least gems.rubyonrails.org. gems.github.com is close to being updated too. >> * RubyGems will now require rubygems/defaults/operating_system.rb and >> rubygems/defaults/#{RBX_ENGINE}.rb if they exist. > > I think that you meant RUBY_ENGINE, not RBX_ENGINGE, right? Yes, I will update the release notes and so-forth. From thewoolleyman at gmail.com Sun Jun 22 17:49:56 2008 From: thewoolleyman at gmail.com (Chad Woolley) Date: Sun, 22 Jun 2008 14:49:56 -0700 Subject: [Rubygems-developers] invalid Gem::Specification format? Message-ID: Hi, I don't have time to look into this myself, but I thought I'd mention it, since it sounds strange and may be some sort of regression. I released a gem (GemInstaller 0.4.2) a couple days before RubyGems 1.2.0, but I used Hoe 1.6.0 with the trunk version of RubyGems installed. Then, I got this report [1] of a stacktrace containing GemInstaller from someone who didn't even have GemInstaller installed. Was this an issue with RubyForge, RubyGems, or my GemInstaller 0.4.2 gem packaging? I also saw this Pastie [2], which may be related??? [1] http://thewoolleyweb.lighthouseapp.com/projects/11580/tickets/12-gem-update-blows-up [2] http://pastie.org/pastes/219563 Thanks, -- Chad From drbrain at segment7.net Sun Jun 22 20:26:11 2008 From: drbrain at segment7.net (Eric Hodel) Date: Sun, 22 Jun 2008 17:26:11 -0700 Subject: [Rubygems-developers] invalid Gem::Specification format? In-Reply-To: References: Message-ID: <5CE0CC81-E9DB-48BF-A40C-B7D3AB442D29@segment7.net> On Jun 22, 2008, at 14:49 PM, Chad Woolley wrote: > I don't have time to look into this myself, but I thought I'd mention > it, since it sounds strange and may be some sort of regression. > > I released a gem (GemInstaller 0.4.2) a couple days before RubyGems > 1.2.0, but I used Hoe 1.6.0 with the trunk version of RubyGems > installed. > > Then, I got this report [1] of a stacktrace containing GemInstaller > from someone who didn't even have GemInstaller installed. Was this an > issue with RubyForge, RubyGems, or my GemInstaller 0.4.2 gem > packaging? > > I also saw this Pastie [2], which may be related??? > > [1] http://thewoolleyweb.lighthouseapp.com/projects/11580/tickets/12-gem-update-blows-up > [2] http://pastie.org/pastes/219563 You'll need to repackage your gem with 1.2.0, 1.1.1 isn't able to load gems from "the future" so I rolled back the specification version since it wasn't really important enough to bump. From neil at brightbox.co.uk Mon Jun 23 11:21:35 2008 From: neil at brightbox.co.uk (Neil Wilson) Date: Mon, 23 Jun 2008 16:21:35 +0100 Subject: [Rubygems-developers] Gem 1.1.1 bulk updating all the time Message-ID: <50d9f33a0806230821g46c250d2wa7a6808814d3eb17@mail.gmail.com> Since the release of 1.2.0 gem v.1.1.1 is constantly bulk updating on every command, with gem install bulk updating twice. Has backward compatibility been broken in some way by a new index format? -- Neil Wilson From luislavena at gmail.com Mon Jun 23 11:30:12 2008 From: luislavena at gmail.com (Luis Lavena) Date: Mon, 23 Jun 2008 17:30:12 +0200 Subject: [Rubygems-developers] Gem 1.1.1 bulk updating all the time In-Reply-To: <50d9f33a0806230821g46c250d2wa7a6808814d3eb17@mail.gmail.com> References: <50d9f33a0806230821g46c250d2wa7a6808814d3eb17@mail.gmail.com> Message-ID: <71166b3b0806230830x36e0f8b8s7a29fc2edea9df5f@mail.gmail.com> On Mon, Jun 23, 2008 at 5:21 PM, Neil Wilson wrote: > Since the release of 1.2.0 gem v.1.1.1 is constantly bulk updating on > every command, with gem install bulk updating twice. > > Has backward compatibility been broken in some way by a new index format? > Hmn, that depends. I had some ruby version with 0.9.4 and sometimes I get bulk updates, but not all the time. With 1.1.1 I get a bulk one If I didn't update in long (but loooong) time, and sometimes get "updating 420 specifications" :-P On one server I got the two times "bulk update" during installation, so kind of weird. -- Luis Lavena AREA 17 - Human beings, who are almost unique in having the ability to learn from the experience of others, are also remarkable for their apparent disinclination to do so. Douglas Adams From drbrain at segment7.net Mon Jun 23 16:19:18 2008 From: drbrain at segment7.net (Eric Hodel) Date: Mon, 23 Jun 2008 13:19:18 -0700 Subject: [Rubygems-developers] Gem 1.1.1 bulk updating all the time In-Reply-To: <50d9f33a0806230821g46c250d2wa7a6808814d3eb17@mail.gmail.com> References: <50d9f33a0806230821g46c250d2wa7a6808814d3eb17@mail.gmail.com> Message-ID: <72147EDD-7A78-43B6-BB3A-0CCC033CF868@segment7.net> On Jun 23, 2008, at 08:21 AM, Neil Wilson wrote: > Since the release of 1.2.0 gem v.1.1.1 is constantly bulk updating on > every command, with gem install bulk updating twice. This was reported before 1.2 was released and may be related to having multiple sources. > Has backward compatibility been broken in some way by a new index > format? I don't think so, but it is possible. I'm no longer supporting Gem::SourceInfoCache, it has grown too many branches to be easily testable (let alone maintainable). If you can demonstrate that the problem lies in the index, I will fix that. Really, though, you should upgrade to 1.2. From ryand-ruby at zenspider.com Mon Jun 23 16:25:42 2008 From: ryand-ruby at zenspider.com (Ryan Davis) Date: Mon, 23 Jun 2008 13:25:42 -0700 Subject: [Rubygems-developers] Gem 1.1.1 bulk updating all the time In-Reply-To: <72147EDD-7A78-43B6-BB3A-0CCC033CF868@segment7.net> References: <50d9f33a0806230821g46c250d2wa7a6808814d3eb17@mail.gmail.com> <72147EDD-7A78-43B6-BB3A-0CCC033CF868@segment7.net> Message-ID: <674DCD46-6EEE-405B-8959-BA20854F3360@zenspider.com> On Jun 23, 2008, at 13:19 , Eric Hodel wrote: > On Jun 23, 2008, at 08:21 AM, Neil Wilson wrote: >> Since the release of 1.2.0 gem v.1.1.1 is constantly bulk updating on >> every command, with gem install bulk updating twice. > > This was reported before 1.2 was released and may be related to > having multiple sources. or cache/permission issues. I had 100% bulk updates for a few weeks and it went away. At the very least, try resetting stuff back to the basics: sudo gem sources -c sudo gem sources -l # to list every source you have sudo gem -r uri # remove every one but rubyforge.org From rick.denatale at gmail.com Mon Jun 23 16:42:32 2008 From: rick.denatale at gmail.com (Rick DeNatale) Date: Mon, 23 Jun 2008 16:42:32 -0400 Subject: [Rubygems-developers] Gem 1.1.1 bulk updating all the time In-Reply-To: <674DCD46-6EEE-405B-8959-BA20854F3360@zenspider.com> References: <50d9f33a0806230821g46c250d2wa7a6808814d3eb17@mail.gmail.com> <72147EDD-7A78-43B6-BB3A-0CCC033CF868@segment7.net> <674DCD46-6EEE-405B-8959-BA20854F3360@zenspider.com> Message-ID: On Mon, Jun 23, 2008 at 4:25 PM, Ryan Davis wrote: > At the very least, try resetting stuff back to the basics: > > sudo gem sources -c > sudo gem sources -l # to list every source you have > sudo gem -r uri # remove every one but rubyforge.org should that be rubyforge.org, or gems.rubyforge.org? $ sudo gem sources -l *** CURRENT SOURCES *** http://gems.rubyforge.org -- Rick DeNatale My blog on Ruby http://talklikeaduck.denhaven2.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryand-ruby at zenspider.com Mon Jun 23 17:12:05 2008 From: ryand-ruby at zenspider.com (Ryan Davis) Date: Mon, 23 Jun 2008 14:12:05 -0700 Subject: [Rubygems-developers] Gem 1.1.1 bulk updating all the time In-Reply-To: References: <50d9f33a0806230821g46c250d2wa7a6808814d3eb17@mail.gmail.com> <72147EDD-7A78-43B6-BB3A-0CCC033CF868@segment7.net> <674DCD46-6EEE-405B-8959-BA20854F3360@zenspider.com> Message-ID: <56B51F80-7AC7-4309-80C5-D6B78B50DDBE@zenspider.com> On Jun 23, 2008, at 13:42 , Rick DeNatale wrote: > On Mon, Jun 23, 2008 at 4:25 PM, Ryan Davis ruby at zenspider.com> wrote: > At the very least, try resetting stuff back to the basics: > > sudo gem sources -c > sudo gem sources -l # to list every source you have > sudo gem -r uri # remove every one but rubyforge.org > > should that be rubyforge.org, or gems.rubyforge.org? > > $ sudo gem sources -l > *** CURRENT SOURCES *** > > http://gems.rubyforge.org gems.rubyforge.org is correct. From thewoolleyman at gmail.com Mon Jun 23 18:48:44 2008 From: thewoolleyman at gmail.com (Chad Woolley) Date: Mon, 23 Jun 2008 15:48:44 -0700 Subject: [Rubygems-developers] invalid Gem::Specification format? In-Reply-To: <5CE0CC81-E9DB-48BF-A40C-B7D3AB442D29@segment7.net> References: <5CE0CC81-E9DB-48BF-A40C-B7D3AB442D29@segment7.net> Message-ID: On Sun, Jun 22, 2008 at 5:26 PM, Eric Hodel wrote: > You'll need to repackage your gem with 1.2.0, 1.1.1 isn't able to load gems > from "the future" so I rolled back the specification version since it wasn't > really important enough to bump. OK, I revved my gem version and packaged/released it with rubygems 1.2.0 official release installed. This should make everything right? From thewoolleyman at gmail.com Mon Jun 23 21:17:25 2008 From: thewoolleyman at gmail.com (Chad Woolley) Date: Mon, 23 Jun 2008 18:17:25 -0700 Subject: [Rubygems-developers] Bug? - Users having to manually delete cached gems after 1.2.0 upgrade (windows only) Message-ID: Some coworkers today reported this situation on windows, haven't tried to reproduce: 1. upgrade to rubygems 1.2.0 2. try to install a gem, get error: 'invalid gem format for whatever.gem' 3. manually delete the gem from /cache, and install then works Gems were Selenium gem, and activesupport-2.1.0 From ryand-ruby at zenspider.com Mon Jun 23 23:26:01 2008 From: ryand-ruby at zenspider.com (Ryan Davis) Date: Mon, 23 Jun 2008 20:26:01 -0700 Subject: [Rubygems-developers] invalid Gem::Specification format? In-Reply-To: References: <5CE0CC81-E9DB-48BF-A40C-B7D3AB442D29@segment7.net> Message-ID: <7AC4322C-5501-4FD3-A3F0-4A995EFCC776@zenspider.com> On Jun 23, 2008, at 15:48 , Chad Woolley wrote: > OK, I revved my gem version and packaged/released it with rubygems > 1.2.0 official release installed. This should make everything right? should... I'll wait an hour and poke it. (how often is the index generated?) From ryand-ruby at zenspider.com Tue Jun 24 00:49:04 2008 From: ryand-ruby at zenspider.com (Ryan Davis) Date: Mon, 23 Jun 2008 21:49:04 -0700 Subject: [Rubygems-developers] invalid Gem::Specification format? In-Reply-To: <7AC4322C-5501-4FD3-A3F0-4A995EFCC776@zenspider.com> References: <5CE0CC81-E9DB-48BF-A40C-B7D3AB442D29@segment7.net> <7AC4322C-5501-4FD3-A3F0-4A995EFCC776@zenspider.com> Message-ID: On Jun 23, 2008, at 20:26 , Ryan Davis wrote: > > On Jun 23, 2008, at 15:48 , Chad Woolley wrote: > >> OK, I revved my gem version and packaged/released it with rubygems >> 1.2.0 official release installed. This should make everything right? > > should... I'll wait an hour and poke it. nope... don't look like it. From neil at brightbox.co.uk Tue Jun 24 03:46:44 2008 From: neil at brightbox.co.uk (Neil Wilson) Date: Tue, 24 Jun 2008 08:46:44 +0100 Subject: [Rubygems-developers] Gem 1.1.1 bulk updating all the time In-Reply-To: <674DCD46-6EEE-405B-8959-BA20854F3360@zenspider.com> References: <50d9f33a0806230821g46c250d2wa7a6808814d3eb17@mail.gmail.com> <72147EDD-7A78-43B6-BB3A-0CCC033CF868@segment7.net> <674DCD46-6EEE-405B-8959-BA20854F3360@zenspider.com> Message-ID: <50d9f33a0806240046h4a2a6d40rf8559fc5c1b5445a@mail.gmail.com> 2008/6/23 Ryan Davis : > or cache/permission issues. I had 100% bulk updates for a few weeks and it > went away. At the very least, try resetting stuff back to the basics: > > sudo gem sources -c > sudo gem sources -l # to list every source you have > sudo gem -r uri # remove every one but rubyforge.org Yeah I've done that. Unfortunately the machines in question are 256Mb VPS Ubuntu Dapper installations and the bulk update procedure seems to need about twice that, so the poor little things thrash themselves into oblivion. -- Neil Wilson From neil at brightbox.co.uk Tue Jun 24 03:55:36 2008 From: neil at brightbox.co.uk (Neil Wilson) Date: Tue, 24 Jun 2008 08:55:36 +0100 Subject: [Rubygems-developers] Gem 1.1.1 bulk updating all the time In-Reply-To: <72147EDD-7A78-43B6-BB3A-0CCC033CF868@segment7.net> References: <50d9f33a0806230821g46c250d2wa7a6808814d3eb17@mail.gmail.com> <72147EDD-7A78-43B6-BB3A-0CCC033CF868@segment7.net> Message-ID: <50d9f33a0806240055x6c6525ffy38f9c4588a4f019f@mail.gmail.com> 2008/6/23 Eric Hodel : > Really, though, you should upgrade to 1.2. 1.2.0 is definitely a lot better at first glance. With my sysadmin hat on I prefer to give software a good time to bed in before recommending an upgrade. However in this case the problems with our 256Mb machines are pretty much insurmountable so I'll just have to trust that your testing regime is sufficiently rigorous ;-) -- Neil Wilson From thewoolleyman at gmail.com Tue Jun 24 04:08:10 2008 From: thewoolleyman at gmail.com (Chad Woolley) Date: Tue, 24 Jun 2008 01:08:10 -0700 Subject: [Rubygems-developers] invalid Gem::Specification format? In-Reply-To: References: <5CE0CC81-E9DB-48BF-A40C-B7D3AB442D29@segment7.net> <7AC4322C-5501-4FD3-A3F0-4A995EFCC776@zenspider.com> Message-ID: On Mon, Jun 23, 2008 at 9:49 PM, Ryan Davis wrote: > nope... don't look like it. Not sure what you mean. You mean my 0.4.3 has not propagated to your mirror, or you are able to reproduce the original error with my 0.4.3 version? From hongli at phusion.nl Tue Jun 24 04:31:33 2008 From: hongli at phusion.nl (Hongli Lai) Date: Tue, 24 Jun 2008 10:31:33 +0200 Subject: [Rubygems-developers] Gem 1.1.1 bulk updating all the time In-Reply-To: <50d9f33a0806240055x6c6525ffy38f9c4588a4f019f@mail.gmail.com> References: <50d9f33a0806230821g46c250d2wa7a6808814d3eb17@mail.gmail.com> <72147EDD-7A78-43B6-BB3A-0CCC033CF868@segment7.net> <50d9f33a0806240055x6c6525ffy38f9c4588a4f019f@mail.gmail.com> Message-ID: <4860B0E5.5060303@phusion.nl> Neil Wilson wrote: > 2008/6/23 Eric Hodel : > >> Really, though, you should upgrade to 1.2. > > 1.2.0 is definitely a lot better at first glance. With my sysadmin hat > on I prefer to give software a good time to bed in before recommending > an upgrade. However in this case the problems with our 256Mb machines > are pretty much insurmountable so I'll just have to trust that your > testing regime is sufficiently rigorous ;-) > I tested RubyGems 1.2 on an OpenBSD VM with 256 MB RAM and no swap. It worked fine, and installation was fast too. This is what I did: gem source -u gem install rails --no-rdoc --no-ri --no-update-sources gem install something_else --no-rdoc --no-ri --no-update-sources -- Phusion | The Computer Science Company Web: http://www.phusion.nl/ E-mail: info at phusion.nl Chamber of commerce no: 08173483 (The Netherlands) From jeremydeininger at gmail.com Tue Jun 24 12:53:14 2008 From: jeremydeininger at gmail.com (Jeremy d) Date: Tue, 24 Jun 2008 09:53:14 -0700 Subject: [Rubygems-developers] invalid Gem::Specification format Message-ID: Hello, I'm currently using rubygems version 1.0.1 with the --no-update-sources option. Basically, I'm doing a 'gem sources -u' to refresh the index, and then a gem install rails --version 1.2.3 --no-update-sources for speedup reasons. When the new mirror came online this weekend gem was no longer able to find gems in the sources cache. I'm including the debug output below, it seems that one of the gemspecs is not recognized by version 1.0.1 as a valid format (possible the version string?) Is this behavior a bug or desired behavior? Without the --no-update-sources option gem successfully does a bulk update and the installation succeeds. Thanks! -Jeremy Exception `TypeError' at /usr/lib/ruby/site_ruby/1.8/rubygems/specification.rb:271 - invalid Gem::Specification format ["1.1.1", 3, "geminstaller", #, Thu Jun 19 03:00:00 -0400 2008, "Automated Gem installation, activation, and much more!", #=", #]]>, #=", #]]>, "ruby", [], "geminstaller", "thewoolleyman at gmail.com", ["Chad Woolley"], "Automated Gem installation, activation, and much more! == FEATURES: GemInstaller provides automated installation, loading and activation of RubyGems. It uses a simple YAML config file to: * Automatically install the correct versions of all required gems wherever your app runs. * Automatically ensure installed gems and versions are consistent across multiple applications, machines, platforms, and environments * Automatically activate correct versions of gems on the ruby load path when your app runs ('require_gem'/'gem') * Automatically reinstall missing dependency gems (built in to RubyGems > 1.0) * Automatically detect correct platform to install for multi-platform gems (built in to RubyGems > 1.0) * Print YAML for \"rogue gems\" which are not specified in the current config, to easily bootstrap your config file, or find gems that were manually installed without GemInstaller. * Allow for common configs to be reused across projects or environments by supporting multiple config files, including common config file snippets, and defaults with overrides. * Allow for dynamic selection of gems, versions, and platforms to be used based on environment vars or any other logic. * Avoid the \"works on demo, breaks on production\" syndrome * Solve world hunger, prevent the global energy crisis, and wash your socks. == SYNOPSYS:", " by Chad Woolley", true, "ruby"] Exception `Gem::GemNotFoundException' at /usr/lib/ruby/site_ruby/1.8/rubygems/dependency_installer.rb:87 - could not find rails locally or in a repository ERROR: could not find rails locally or in a repository From thewoolleyman at gmail.com Tue Jun 24 16:41:38 2008 From: thewoolleyman at gmail.com (Chad Woolley) Date: Tue, 24 Jun 2008 13:41:38 -0700 Subject: [Rubygems-developers] invalid Gem::Specification format In-Reply-To: References: Message-ID: On Tue, Jun 24, 2008 at 9:53 AM, Jeremy d wrote: > Exception `TypeError' at > /usr/lib/ruby/site_ruby/1.8/rubygems/specification.rb:271 - invalid > Gem::Specification format ["1.1.1", 3, "geminstaller", # "0.4.2">, Thu Jun 19 03:00:00 -0400 2008, "Automated Gem installation, Hi, This was apparently because I built the GemInstaller 0.4.2 gem with a pre-1.2.0 release of RubyGems. I have since re-released GemInstaller 0.4.3 built with RubyGems 1.2.0 official, and deleted the 0.4.2 release off of RubyForge. I hope this fixes everything! From ryand-ruby at zenspider.com Tue Jun 24 19:07:06 2008 From: ryand-ruby at zenspider.com (Ryan Davis) Date: Tue, 24 Jun 2008 16:07:06 -0700 Subject: [Rubygems-developers] invalid Gem::Specification format In-Reply-To: References: Message-ID: On Jun 24, 2008, at 13:41 , Chad Woolley wrote: > On Tue, Jun 24, 2008 at 9:53 AM, Jeremy d > wrote: >> Exception `TypeError' at >> /usr/lib/ruby/site_ruby/1.8/rubygems/specification.rb:271 - invalid >> Gem::Specification format ["1.1.1", 3, "geminstaller", #> "0.4.2">, Thu Jun 19 03:00:00 -0400 2008, "Automated Gem >> installation, > > Hi, > > This was apparently because I built the GemInstaller 0.4.2 gem with a > pre-1.2.0 release of RubyGems. > > I have since re-released GemInstaller 0.4.3 built with RubyGems 1.2.0 > official, and deleted the 0.4.2 release off of RubyForge. I hope this > fixes everything! deletions don't replicate, unfortunately... it'd be quicker and easier (until we get ahold of tom) to push another 0.4.2. Sucks... I've been bitten by this before too. From ryand-ruby at zenspider.com Tue Jun 24 19:08:22 2008 From: ryand-ruby at zenspider.com (Ryan Davis) Date: Tue, 24 Jun 2008 16:08:22 -0700 Subject: [Rubygems-developers] invalid Gem::Specification format? In-Reply-To: References: <5CE0CC81-E9DB-48BF-A40C-B7D3AB442D29@segment7.net> <7AC4322C-5501-4FD3-A3F0-4A995EFCC776@zenspider.com> Message-ID: <9EDDD1B2-D4C7-4C0C-B0AE-4AC993CDDF28@zenspider.com> On Jun 24, 2008, at 01:08 , Chad Woolley wrote: > On Mon, Jun 23, 2008 at 9:49 PM, Ryan Davis ruby at zenspider.com> wrote: >> nope... don't look like it. > > Not sure what you mean. You mean my 0.4.3 has not propagated to your > mirror, or you are able to reproduce the original error with my 0.4.3 > version? you and I are already caught up, but for the record: 0.4.3 was fixed but 0.4.2 still has the same problem. 0.4.2 was deleted but that doesn't replicate so it should be rereleased as well (unless we can find tom online) From thewoolleyman at gmail.com Wed Jun 25 00:26:31 2008 From: thewoolleyman at gmail.com (Chad Woolley) Date: Tue, 24 Jun 2008 21:26:31 -0700 Subject: [Rubygems-developers] invalid Gem::Specification format? In-Reply-To: <9EDDD1B2-D4C7-4C0C-B0AE-4AC993CDDF28@zenspider.com> References: <5CE0CC81-E9DB-48BF-A40C-B7D3AB442D29@segment7.net> <7AC4322C-5501-4FD3-A3F0-4A995EFCC776@zenspider.com> <9EDDD1B2-D4C7-4C0C-B0AE-4AC993CDDF28@zenspider.com> Message-ID: On Tue, Jun 24, 2008 at 4:08 PM, Ryan Davis wrote: > you and I are already caught up, but for the record: 0.4.3 was fixed but > 0.4.2 still has the same problem. 0.4.2 was deleted but that doesn't > replicate so it should be rereleased as well (unless we can find tom online) OK, I just re-released from my 0.4.2 tag, packaged with RubyGems 1.2.0 release. I still am not sure how to reproduce this error, can you confirm or tell me how to check? Thanks, -- Chad From ryand-ruby at zenspider.com Wed Jun 25 02:14:38 2008 From: ryand-ruby at zenspider.com (Ryan Davis) Date: Tue, 24 Jun 2008 23:14:38 -0700 Subject: [Rubygems-developers] invalid Gem::Specification format? In-Reply-To: References: <5CE0CC81-E9DB-48BF-A40C-B7D3AB442D29@segment7.net> <7AC4322C-5501-4FD3-A3F0-4A995EFCC776@zenspider.com> <9EDDD1B2-D4C7-4C0C-B0AE-4AC993CDDF28@zenspider.com> Message-ID: <55513113-35AE-41FF-BE12-64C84AF1A909@zenspider.com> On Jun 24, 2008, at 21:26 , Chad Woolley wrote: > On Tue, Jun 24, 2008 at 4:08 PM, Ryan Davis ruby at zenspider.com> wrote: >> you and I are already caught up, but for the record: 0.4.3 was >> fixed but >> 0.4.2 still has the same problem. 0.4.2 was deleted but that doesn't >> replicate so it should be rereleased as well (unless we can find >> tom online) > > OK, I just re-released from my 0.4.2 tag, packaged with RubyGems > 1.2.0 release. > > I still am not sure how to reproduce this error, can you confirm or > tell me how to check? gah... lame. I have no idea what's wrong now: 502 % sudo gem sources -c; sudo gem update --system --debug; gem -v Password: *** Removed user source cache *** *** Removed latest user source cache *** *** Removed system source cache *** *** Removed latest system source cache *** Exception `NameError' at /Library/Ruby/Site/1.8/rubygems/ command_manager.rb:133 - uninitialized constant Gem::Commands::UpdateCommand Updating RubyGems Exception `Errno::ENOENT' at /Library/Ruby/Site/1.8/rubygems/ source_info_cache.rb:206 - No such file or directory - /Library/Ruby/ Gems/1.8/latest_source_cache Bulk updating Gem source index for: http://gems.rubyforge.org/ Nothing to update 1.1.1 From thewoolleyman at gmail.com Wed Jun 25 11:34:27 2008 From: thewoolleyman at gmail.com (Chad Woolley) Date: Wed, 25 Jun 2008 08:34:27 -0700 Subject: [Rubygems-developers] invalid Gem::Specification format? In-Reply-To: <55513113-35AE-41FF-BE12-64C84AF1A909@zenspider.com> References: <5CE0CC81-E9DB-48BF-A40C-B7D3AB442D29@segment7.net> <7AC4322C-5501-4FD3-A3F0-4A995EFCC776@zenspider.com> <9EDDD1B2-D4C7-4C0C-B0AE-4AC993CDDF28@zenspider.com> <55513113-35AE-41FF-BE12-64C84AF1A909@zenspider.com> Message-ID: On Tue, Jun 24, 2008 at 11:14 PM, Ryan Davis wrote: > gah... lame. I have no idea what's wrong now: I get something similar - but maybe this isn't a problem with my gem anymore? Anyway, I got a ton of spew when I ran this initially (with 1.2.0 released version already installed): chadmac:~ woolley$ sudo gem sources -c; sudo gem update --system --debug; gem -v Password: *** Removed specs cache *** *** Removed user source cache *** *** Removed latest user source cache *** *** Removed system source cache *** *** Removed latest system source cache *** Exception `NameError' at /Library/Ruby/Site/1.8/rubygems/command_manager.rb:134 - uninitialized constant Gem::Commands::UpdateCommand Updating RubyGems Updating rubygems-update Exception `IOError' at /Library/Ruby/Site/1.8/rubygems/format.rb:50 - closed stream Exception `Errno::EEXIST' at /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/fileutils.rb:243 - File exists - /Library/Ruby/Gems/1.8/gems/rubygems-update-1.2.0 <.....snip a lot of the same ...> Successfully installed rubygems-update-1.2.0 Exception `NameError' at /Library/Ruby/Site/1.8/rubygems/commands/update_command.rb:87 - undefined local variable or method `remote_gemspecs' for # ERROR: While executing gem ... (NameError) undefined local variable or method `remote_gemspecs' for # /Library/Ruby/Site/1.8/rubygems/commands/update_command.rb:87:in `execute' /Library/Ruby/Site/1.8/rubygems/command.rb:136:in `invoke' /Library/Ruby/Site/1.8/rubygems/command_manager.rb:105:in `process_args' /Library/Ruby/Site/1.8/rubygems/command_manager.rb:75:in `run' /Library/Ruby/Site/1.8/rubygems/gem_runner.rb:39:in `run' /usr/bin/gem:24 1.2.0 Then, after I remove ~/.gem (for user, not root), I only get one error: chadmac:~ woolley$ sudo gem sources -c; sudo gem update --system --debug; gem -v *** Removed specs cache *** *** Removed user source cache *** *** Removed latest user source cache *** *** Removed system source cache *** *** Removed latest system source cache *** Exception `NameError' at /Library/Ruby/Site/1.8/rubygems/command_manager.rb:134 - uninitialized constant Gem::Commands::UpdateCommand Updating RubyGems Nothing to update 1.2.0 Not sure if the errors went away because of partial install success, or deleting the non-root ~/.gem? Looks like there are some upgrade issues, but they go away, except for the command_manager missing constant... -- Chad From vsizikov at gmail.com Wed Jun 25 17:10:49 2008 From: vsizikov at gmail.com (Vladimir Sizikov) Date: Wed, 25 Jun 2008 23:10:49 +0200 Subject: [Rubygems-developers] Customizing rubygems via #{RUBY_ENGINE}.rb Message-ID: <3454c9680806251410q7f66fd3as3ad0567bec95c91d@mail.gmail.com> Hi guys, I'm currently in a process of upgrading JRuby trunk with the latest rubygems 1.2, and trying to use the new feature to provide some JRuby specific customization to rubygems via #{RUBY_ENGINE}.rb file. It worked very well in some cases, but I'm facing some problems when I try to customize things like commands, since that RUBY_ENGINE.rb file is loaded at the end of rubygems.rb file but *before* other things like commands are loaded. Here are some use cases that I'd like to resolve somehow: 1. gem install and gem update commands. I'd like to customize the default options. More specifically, to enable env_shebang option. 2. installer.rb has shebang(bin_file_name) method that works not ideally with JRuby on Windows, and I'd like to provide customized version of that. In both cases, I can't redefine/monkey-patch those things from #{RUBY_ENGINE}.rb. Any suggestions? Thank you, --Vladimir P.S. So far, rubygems 1.2 looks *very* impressive speed- and memory-wise. Thanks!! From drbrain at segment7.net Wed Jun 25 17:40:53 2008 From: drbrain at segment7.net (Eric Hodel) Date: Wed, 25 Jun 2008 14:40:53 -0700 Subject: [Rubygems-developers] invalid Gem::Specification format? In-Reply-To: <55513113-35AE-41FF-BE12-64C84AF1A909@zenspider.com> References: <5CE0CC81-E9DB-48BF-A40C-B7D3AB442D29@segment7.net> <7AC4322C-5501-4FD3-A3F0-4A995EFCC776@zenspider.com> <9EDDD1B2-D4C7-4C0C-B0AE-4AC993CDDF28@zenspider.com> <55513113-35AE-41FF-BE12-64C84AF1A909@zenspider.com> Message-ID: <920A604B-7D3B-4D06-927F-473FE6EF361F@segment7.net> On Jun 24, 2008, at 23:14 PM, Ryan Davis wrote: > On Jun 24, 2008, at 21:26 , Chad Woolley wrote: >> On Tue, Jun 24, 2008 at 4:08 PM, Ryan Davis > ruby at zenspider.com> wrote: >>> you and I are already caught up, but for the record: 0.4.3 was >>> fixed but >>> 0.4.2 still has the same problem. 0.4.2 was deleted but that doesn't >>> replicate so it should be rereleased as well (unless we can find >>> tom online) >> >> OK, I just re-released from my 0.4.2 tag, packaged with RubyGems >> 1.2.0 release. >> >> I still am not sure how to reproduce this error, can you confirm or >> tell me how to check? > > gah... lame. I have no idea what's wrong now: > > [...] > Nothing to update Separate bug in the update command. The workaround is to `gem install rubygems-update -v 1.1.1` before `gem update --system`. From drbrain at segment7.net Wed Jun 25 17:46:42 2008 From: drbrain at segment7.net (Eric Hodel) Date: Wed, 25 Jun 2008 14:46:42 -0700 Subject: [Rubygems-developers] Customizing rubygems via #{RUBY_ENGINE}.rb In-Reply-To: <3454c9680806251410q7f66fd3as3ad0567bec95c91d@mail.gmail.com> References: <3454c9680806251410q7f66fd3as3ad0567bec95c91d@mail.gmail.com> Message-ID: <02FB6BCF-B67A-4606-9209-F0427621F37E@segment7.net> On Jun 25, 2008, at 14:10 PM, Vladimir Sizikov wrote: > I'm currently in a process of upgrading JRuby trunk with the latest > rubygems 1.2, and > trying to use the new feature to provide some JRuby specific > customization to rubygems via > #{RUBY_ENGINE}.rb file. > > It worked very well in some cases, but I'm facing some problems when I > try to customize > things like commands, since that RUBY_ENGINE.rb file is loaded at the > end of rubygems.rb > file but *before* other things like commands are loaded. > > Here are some use cases that I'd like to resolve somehow: > > 1. gem install and gem update commands. I'd like to customize the > default options. > More specifically, to enable env_shebang option. I think Gem::ConfigFile can be changed to set this as default. I'll explore it. > 2. installer.rb has shebang(bin_file_name) method that works not > ideally with JRuby on Windows, > and I'd like to provide customized version of that. How do you want to change shebang? Maybe we can make the change in the installer instead. From vsizikov at gmail.com Wed Jun 25 17:53:58 2008 From: vsizikov at gmail.com (Vladimir Sizikov) Date: Wed, 25 Jun 2008 23:53:58 +0200 Subject: [Rubygems-developers] Customizing rubygems via #{RUBY_ENGINE}.rb In-Reply-To: <02FB6BCF-B67A-4606-9209-F0427621F37E@segment7.net> References: <3454c9680806251410q7f66fd3as3ad0567bec95c91d@mail.gmail.com> <02FB6BCF-B67A-4606-9209-F0427621F37E@segment7.net> Message-ID: <3454c9680806251453x1d38089cl20c8cc74f35072a5@mail.gmail.com> Hi Eric, Thanks for very quick response! On Wed, Jun 25, 2008 at 11:46 PM, Eric Hodel wrote: >> 1. gem install and gem update commands. I'd like to customize the >> default options. >> More specifically, to enable env_shebang option. > > I think Gem::ConfigFile can be changed to set this as default. I'll explore > it. The ideal case would be to have zero "hacks/patches" over official rubygems sources, so if there is a way to provide command defaults and not modifying the official sources, that would be the best. I think #{RUBY_ENGINE}.rb is a good start. >> 2. installer.rb has shebang(bin_file_name) method that works not >> ideally with JRuby on Windows, >> and I'd like to provide customized version of that. > > How do you want to change shebang? Maybe we can make the change in the > installer instead. In JRuby, the main executable name on Windows is jruby.bat. If you have the shebang: #!/usr/bin/env jruby.bat That won't work on Cygwin, but #!/usr/bin/env jruby - will work So, we currently modify that shebang method to return the appropriate one. Thanks, --Vladimir From jeremydeininger at gmail.com Wed Jun 25 19:11:01 2008 From: jeremydeininger at gmail.com (Jeremy d) Date: Wed, 25 Jun 2008 16:11:01 -0700 Subject: [Rubygems-developers] invalid Gem::Specification format In-Reply-To: References: Message-ID: On Tue, Jun 24, 2008 at 4:07 PM, Ryan Davis wrote: > > On Jun 24, 2008, at 13:41 , Chad Woolley wrote: > >> On Tue, Jun 24, 2008 at 9:53 AM, Jeremy d >> wrote: >>> >>> Exception `TypeError' at >>> /usr/lib/ruby/site_ruby/1.8/rubygems/specification.rb:271 - invalid >>> Gem::Specification format ["1.1.1", 3, "geminstaller", #>> "0.4.2">, Thu Jun 19 03:00:00 -0400 2008, "Automated Gem installation, >> >> Hi, >> >> This was apparently because I built the GemInstaller 0.4.2 gem with a >> pre-1.2.0 release of RubyGems. >> >> I have since re-released GemInstaller 0.4.3 built with RubyGems 1.2.0 >> official, and deleted the 0.4.2 release off of RubyForge. I hope this >> fixes everything! > > deletions don't replicate, unfortunately... it'd be quicker and easier > (until we get ahold of tom) to push another 0.4.2. Sucks... I've been bitten > by this before too._______________________________________________ > Rubygems-developers mailing list > Rubygems-developers at rubyforge.org > http://rubyforge.org/mailman/listinfo/rubygems-developers > Chad, The re-release of 0.4.2 fixed the problem I was encountering. Thanks! -Jeremy From drbrain at segment7.net Wed Jun 25 19:50:58 2008 From: drbrain at segment7.net (Eric Hodel) Date: Wed, 25 Jun 2008 16:50:58 -0700 Subject: [Rubygems-developers] Customizing rubygems via #{RUBY_ENGINE}.rb In-Reply-To: <3454c9680806251453x1d38089cl20c8cc74f35072a5@mail.gmail.com> References: <3454c9680806251410q7f66fd3as3ad0567bec95c91d@mail.gmail.com> <02FB6BCF-B67A-4606-9209-F0427621F37E@segment7.net> <3454c9680806251453x1d38089cl20c8cc74f35072a5@mail.gmail.com> Message-ID: <8E05BEB7-FD7A-463F-A898-0713681C4419@segment7.net> On Jun 25, 2008, at 14:53 PM, Vladimir Sizikov wrote: > On Wed, Jun 25, 2008 at 11:46 PM, Eric Hodel > wrote: > >>> 1. gem install and gem update commands. I'd like to customize the >>> default options. >>> More specifically, to enable env_shebang option. >> >> I think Gem::ConfigFile can be changed to set this as default. >> I'll explore >> it. > > The ideal case would be to have zero "hacks/patches" over official > rubygems sources, so if there is a way to provide command defaults and > not modifying > the official sources, that would be the best. > > I think #{RUBY_ENGINE}.rb is a good start. Ok, I added Gem::ConfigFile::OPERATING_SYSTEM_DEFAULTS and PLATFORM_DEFAULTS. Add: Gem::ConfigFile::PLATFORM_DEFAULTS['install'] = '--env-shebang' Gem::ConfigFile::PLATFORM_DEFAULTS['update'] = '--env-shebang' I think this will work for `gem update`, but I'm not sure. Can you let me know if it doesn't work? (In the future, Gem::InstallUpdateOptions needs to be connected into these common options, I'm not sure how to do that yet.) >>> 2. installer.rb has shebang(bin_file_name) method that works not >>> ideally with JRuby on Windows, >>> and I'd like to provide customized version of that. >> >> How do you want to change shebang? Maybe we can make the change in >> the >> installer instead. > > In JRuby, the main executable name on Windows is jruby.bat. If you > have the shebang: > #!/usr/bin/env jruby.bat > > That won't work on Cygwin, but > #!/usr/bin/env jruby - will work > > So, we currently modify that shebang method to return the > appropriate one. I saw your paste (http://pastie.org/222204) with the change you're making to Installer. Do you think an overridable Gem.ruby_executable_name would be sufficient? By default it would be Gem::ConfigMap[:ruby_install_name]. From neil at brightbox.co.uk Thu Jun 26 01:42:57 2008 From: neil at brightbox.co.uk (Neil Wilson) Date: Thu, 26 Jun 2008 06:42:57 +0100 Subject: [Rubygems-developers] Customising Rubygems for Debian/Ubuntu. Message-ID: <50d9f33a0806252242o70d39d45x469be3a252d1d11a@mail.gmail.com> I'm currently working on an improved native 'apt' package for Debian/Ubuntu that will allow 'gem' and 'apt' to work together interchangeably on a Debian/Ubuntu platform *and* be compatible with Debian's filesystem policies. To do that I need to use the 'alternatives' system so that the OS knows which is the current version of an application. Essentially gem will install an 'app1.8' or 'app1.9' link to the relevant binary and the 'alternatives' system will create 'app' in the system path. What I need to do is call the command 'update-alternatives' on install and deinstall, which corresponds to the 'postinst' and 'prerm' scripts you get under 'apt' packaging. However I can't see any prebuilt hooks (empty methods would do) in the code that I can override with the new 'operating_system.rb' file. Any chance of putting in simple hook methods in the relevant place? What I could do with is - 'preinst' and 'postinst' called at the relevant places in install - 'prerm' and 'postrm' called at relevant places in uninstall - 'update-system' called when gem is doing an 'update --system' so that I can redirect that to use 'apt' instead'. Of course any other suggestions on how to get this done gratefully received. -- Neil Wilson From drbrain at segment7.net Thu Jun 26 22:21:18 2008 From: drbrain at segment7.net (Eric Hodel) Date: Thu, 26 Jun 2008 19:21:18 -0700 Subject: [Rubygems-developers] Customising Rubygems for Debian/Ubuntu. In-Reply-To: <50d9f33a0806252242o70d39d45x469be3a252d1d11a@mail.gmail.com> References: <50d9f33a0806252242o70d39d45x469be3a252d1d11a@mail.gmail.com> Message-ID: On Jun 25, 2008, at 22:42 PM, Neil Wilson wrote: > To do that I need to use the 'alternatives' system so that the OS > knows which is the current version of an application. Essentially gem > will install an 'app1.8' or 'app1.9' link to the relevant binary and > the 'alternatives' system will create 'app' in the system path. Is this for `gem` itself or for a gem-installed executable? From drbrain at segment7.net Thu Jun 26 22:22:42 2008 From: drbrain at segment7.net (Eric Hodel) Date: Thu, 26 Jun 2008 19:22:42 -0700 Subject: [Rubygems-developers] Customising Rubygems for Debian/Ubuntu. In-Reply-To: References: <50d9f33a0806252242o70d39d45x469be3a252d1d11a@mail.gmail.com> Message-ID: On Jun 26, 2008, at 19:21 PM, Eric Hodel wrote: > On Jun 25, 2008, at 22:42 PM, Neil Wilson wrote: >> To do that I need to use the 'alternatives' system so that the OS >> knows which is the current version of an application. Essentially gem >> will install an 'app1.8' or 'app1.9' link to the relevant binary and >> the 'alternatives' system will create 'app' in the system path. > > Is this for `gem` itself or for a gem-installed executable? ... or a apt-installed gem's executable? From sakaia at jp.fujitsu.com Fri Jun 27 01:27:24 2008 From: sakaia at jp.fujitsu.com (Atsushi SAKAI) Date: Fri, 27 Jun 2008 14:27:24 +0900 Subject: [Rubygems-developers] rake build on ruby-libvirt failed on MinGW. Message-ID: <200806270527.m5R5RQH1004668@fjmscan502.ms.jp.fujitsu.com> Hi, I am trying to build ruby-libvirt on MinGW. But it fails on rake build. I am previously checked ext/libvirt/mkmf.log. The logged problem(libvirt not exist) is already solved. But next problem occured. Is there any suggestions? If this ML is not appropriate, please suggest me. ================== $ rake build --trace (in C:/msys/1.0/home/Administrator/work/ruby-libvirt) ** Invoke build (first_time) ** Invoke ext/libvirt/_libvirt.so (first_time) ** Invoke ext/libvirt/Makefile (first_time, not_needed) ** Invoke ext/libvirt/extconf.rb (first_time, not_needed) ** Invoke ext/libvirt/_libvirt.c (first_time, not_needed) ** Execute ext/libvirt/_libvirt.so make make: *** No rule to make target `ruby.h', needed by `_libvirt.o'. Stop. rake aborted! Command failed with status (2): [make...] ==================== Thanks Atsushi SAKAI From luislavena at gmail.com Fri Jun 27 03:49:27 2008 From: luislavena at gmail.com (Luis Lavena) Date: Fri, 27 Jun 2008 09:49:27 +0200 Subject: [Rubygems-developers] rake build on ruby-libvirt failed on MinGW. In-Reply-To: <200806270527.m5R5RQH1004668@fjmscan502.ms.jp.fujitsu.com> References: <200806270527.m5R5RQH1004668@fjmscan502.ms.jp.fujitsu.com> Message-ID: <71166b3b0806270049q40acbc9akff069c7c4331c944@mail.gmail.com> On Fri, Jun 27, 2008 at 7:27 AM, Atsushi SAKAI wrote: > Hi, > > I am trying to build ruby-libvirt on MinGW. > But it fails on rake build. > > I am previously checked ext/libvirt/mkmf.log. > The logged problem(libvirt not exist) is already solved. > But next problem occured. > > Is there any suggestions? Looks like the generated makefile you're using is not adding the correct paths to include and search for ruby.h Besides that I cannot help you, only suggest you to try the rubyinstaller build. > If this ML is not appropriate, please suggest me. > You could get better answers on ruby-talk mailing list. This list is mostly aimed at rubygems stuff, not compilation of extensions (even if there is a gem what you have problems with). -- Luis Lavena AREA 17 - Human beings, who are almost unique in having the ability to learn from the experience of others, are also remarkable for their apparent disinclination to do so. Douglas Adams From neil at brightbox.co.uk Fri Jun 27 04:14:05 2008 From: neil at brightbox.co.uk (Neil Wilson) Date: Fri, 27 Jun 2008 09:14:05 +0100 Subject: [Rubygems-developers] Customising Rubygems for Debian/Ubuntu. In-Reply-To: References: <50d9f33a0806252242o70d39d45x469be3a252d1d11a@mail.gmail.com> Message-ID: <50d9f33a0806270114s2ff4b263r11dfbc42e23b05fb@mail.gmail.com> 2008/6/27 Eric Hodel : > Is this for `gem` itself or for a gem-installed executable? It is for the gem installed exectuable. Gem would install, say, 'mongrel_rails1.8' and then call 'update-alternatives' so that the alternatives system creates the necessary symlinks allowing the user to run 'mongrel_rails'. Rubygems is installed by 'apt' and 'apt' takes care running 'update alternatives' for the 'gem' command. Hence why I want 'update --system' to divert to running 'apt-get'. The general idea is that when the user switches versions of ruby - between 1.8, 1.9, rubinus or jruby the alternatives system causes the symlinks to switch and follow the 'current' flavour of Ruby. That and finally getting installed gem binaries on the PATH in Debian/Ubuntu without violating their file systems policy... In theory then apt packages generated from gems and gems installed directly will co-operate with each other. The nirvana of automatic apt-packages generated directly from gems should then by a SMOP (he says idealistically :-) -- Neil Wilson From drbrain at segment7.net Mon Jun 30 18:46:43 2008 From: drbrain at segment7.net (Eric Hodel) Date: Mon, 30 Jun 2008 15:46:43 -0700 Subject: [Rubygems-developers] Customising Rubygems for Debian/Ubuntu. In-Reply-To: <50d9f33a0806270114s2ff4b263r11dfbc42e23b05fb@mail.gmail.com> References: <50d9f33a0806252242o70d39d45x469be3a252d1d11a@mail.gmail.com> <50d9f33a0806270114s2ff4b263r11dfbc42e23b05fb@mail.gmail.com> Message-ID: <0CEB3E66-8971-4876-96D0-8AD321D6E2FD@segment7.net> On Jun 27, 2008, at 01:14 AM, Neil Wilson wrote: > 2008/6/27 Eric Hodel : >> Is this for `gem` itself or for a gem-installed executable? > > It is for the gem installed exectuable. Gem would install, say, > 'mongrel_rails1.8' and then call 'update-alternatives' so that the > alternatives system creates the necessary symlinks allowing the user > to run 'mongrel_rails'. Ok. In r1829 I have added: Gem.pre_install Gem.post_install Gem.pre_uninstall Gem.post_uninstall each takes a block that is saved then called with the Gem::Installer/ Gem::Uninstaller instance for the gem being installed/uninstalled at the appropriate time. Multiple pre/post install hooks are supported. Gem.post_install do |installer| puts "!!! #{installer.spec.full_name} INSTALLED !!!" end Gem.post_uninstall do |uninstaller| puts "!!! #{uninstaller.spec.full_name} UNINSTALLED !!!" end