On Sep 22, 2008, at 10:01 AM, Jeremy Hinegardner wrote:
Hi all,

I was doing some investigation on gem repositories and I discovered
something on the gems.rubyforge.org repository.

It appears that any gem that is not a Gem::Platform::RUBY has different
platform values between the Marshal.4.8 file and the specs.4.8 file.

For instance in the hpricot gem:

 Marshal non-RUBY gems
     hpricot-0.4-x86-mswin32
     hpricot-0.5-x86-mswin32
     hpricot-0.6-java
     hpricot-0.6-x86-mswin32
     hpricot-0.6.161-java

 Specs non-RUBY gems
     hpricot-0.4-mswin32
     hpricot-0.5-mswin32
     hpricot-0.6-jruby
     hpricot-0.6-mswin32
     hpricot-0.6.161-jruby


The fun part here is that the none of the Marshal named gems exist at the
source_uri/gems/full_name.gem path, only those that are in Specs exist

Is this the correct behavior?

The Marshal file has both platform and original_platform. original_platform is used to find the file to download since legacy gems haven't been renamed (on disk) to be found properly.

specs has only original_platform so it can be as lightweight as possible. Combining name, version and platform gives you the name of a .gemspec file to download that will give you a Gem::Specification with all the information.

RubyGems knows how to turn original_platform into platform in order to match up with the figure-out-your-platform code (at least, for gems released before the figure-it-out code was written).

Is the Marshal.4.8.Z file to not be used to determine the path to gems?

Use Gem::Specification#original_platform instead of #platform if you have a Gem::Specification. Best is to use #full_name.

Should I only access the specs.4.8 and latest_specs.4.8 ?

You should use Gem::SpecFetcher which handles caching for you and is easiest on bandwidth. Don't use Gem::SourceInfoCache as it is deprecated and eventually will be removed. (Code to do a bulk fetch of the Marshal file will stick around, since it is useful for doing things with the entire repository. I'm not sure if I've put in an interface to that separate from SourceInfoCache.)
_______________________________________________
Rubygems-developers mailing list
Rubygems-developers@rubyforge.org
http://rubyforge.org/mailman/listinfo/rubygems-developers

Reply via email to