RubyGems 1.3.7 will introduce an issue where Chef's gem_package won't be able to install arch-specific packages

Corey's twitter report mention that the format of gem list is going to be different and our regex to check for installed versions won't work anymore.

I've installed the prerelease 1.3.7 on one of my rvm rubies. The exact issue AFAICT is that the format of gem list --remote shows available arches. For example:

gem list --remote nokogiri

*** REMOTE GEMS ***

nokogiri (1.4.1 ruby java x86-mingw32 x86-mswin32)

In IRB using backticks, I get shorter output, but still see the arch stuff:

irb(main):001:0> `gem list --remote nokogiri`
=> "nokogiri (1.4.1 ruby java x86-mingw32 x86-mswin32)\nnokogiri-happymapper (0.3.3)\n"

Fixed the regular expression that parses gem list output, now it looks like this:

/^#{@new_resource.package_name} \((.+?)(?: [^\)\.]+)?\)$/

This will work as long as no platforms have dots in the name.

http://github.com/danielsdeleo/chef/tree/CHEF-1168

I pushed the fix to master, with updated specs to prevent regression.

The fix applied in 0.8.14 does not work on gems that have different versions for different architectures. The MySQL gem, for example, looks like this in gem list remote

mysql (2.8.1 ruby x86-mingw32 x86-mswin32, 2.7.3 mswin32)

The provider needs to be updated to handle this case.

ruby -rubygems -e "y Gem.source_index.map { |g, _| g }"

Or from inside of rake:

sh Gem.ruby, "-rubygems", "-e", "Gem.source_index.map { |g, _| g }"

Discussion of RubyGems API usage in this thread:

http://rubyforge.org/pipermail/rubygems-developers/2010-May/005418.html

Current behavior is still broken for mysql gem, patch here:

http://github.com/thewoolleyman/chef/tree/CHEF-1168

Still doesn't use RubyGems API, but it works for mysql gem now.

This is fixed by CHEF-349.

Thanks for the patch Chad, we just chose to go the gems ruby api route as the rubygems team says the output format of the gem commands is subject to frequent change :/