If the YAML engine is changed after the syck_hack.rb file is loaded, then things like the YAML toplevel constant are redefined to point to either Syck or Psych. This therefore screws up being able to always reference YAML::Syck::DefaultKey so on the load of syck_hack.rb, we get everything the way we want it, then stash a reference to DefaultKey in Gem so that we can always refer to it even if the YAML contstant is redefined.
There are 4 yaml library scenarios that are now dealt with: 1) syck on 1.8 2) syck on early 1.9.2 3) syck on later 1.9.2 4) psych on >= 1.9.2 Cases 1 and 2 have syck loaded at YAML::Syck Case 3 has syck loaded at ::Syck Case 4 does not have a Syck constant at all The code now detects and compensates for all 4 of these cases by making sure that there is a YAML::Syck::DefaultKey and Syck::DefaultKey always. Y::S::DK is needed to load yaml created in cases 1 and 2 S::DK is needed to load yaml created by case 3 In all cases, the code now prunes out the DefaultKey objects when the yaml is loaded (#yaml_initialize time). This minimizes the exposure of DefaultKey objects to the rest of the system. If a DefaultKey object shows up misses the pruning code for some reason, our DefaultKey#to_s is there to attempt to force ruby to ignore it and output just a "=" like it should.
Pull request 216 by Josh Lane: rubygems#216
This reverts commit 12f5af4. Appears this has caused any other environment than Windows to fail. Reverting this until further analysis.
Gem::Specification was aggresively caching full_name and cache_file which affected the playing with the gemspec to generate multiple variations from the same instance. This affected users doing manual build of gems and tools like rake-compiler. So far #version= and #platform= affect those. There might be others.