[Rubygems-developers] differing platforms values between Marshal.4.8 and spec.4.8 ?

[Eric Hodel]

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.)