[Rubygems-developers] Overhaul of specification.rb
gsinclair at soyabean.com.au
Fri Aug 6 00:38:53 EDT 2004
> Gavin Sinclair wrote:
>> I took a look today but didn't have very long. It's to do with the
>> way the gem spec is created. If it's deserialized from YAML, then it
>> doesn't go through the #initialize process, which is the problem.
> This isn't the first time a change in the spec object broke
> compatibilities with older Gems. Its something to watch out for in the
Certainly. Fortunately, this was broken in a CVS snapshot, not a release
:) And it was broken as part of a change that tries to strengthen the
gemspec in future.
With the gemspec versioning mechanism I've introduced, it will be possible
to write a method, within or without the Specification class, that converts
an old spec to the latest format. I'm sure noone wants to have to write
any such method, but the possibility is reassuring.
# End of specific response. Overview of interesting Specification
# methods follows. You can try these in IRB (once they're committed;
# I'm writing some of them as we go).
A legacy spec loaded with the new gemspec code should be identifiable like
spec.gemspec_version == Specification::NONEXISTENT_SPECIFICATION_VERSION
(That's the intention. You can't create a legacy spec with current code,
so I haven't unit tested it. I'll just use a YAML data file, though.)
If it's the latest version, then:
spec.gemspec_version == Specification::CURRENT_SPECIFICATION_VERSION
For an English-language description of the versions:
The other (more) interesting thing you can do is this:
# -> [:name, :version, :bindir, :dependencies, ...]
# -> [ [:name, nil], [:bindir, 'bin'], [:dependencies, ], ... ]
# -> 'bin'
# -> [:name, :version, :date, :summary, ...]
# -> false
I'm hoping to use these methods and constants to further improve the
auto-generated GemspecReference documentation.
More information about the Rubygems-developers