From: Gavin Sinclair <gsinclair@...>
Date: 2004-06-25T07:29:25+09:00
Subject: Re: rubygems thoughts

On Friday, June 25, 2004, 8:07:45 AM, Sean wrote:

> On Thursday 24 June 2004 14:01, Jim Weirich wrote:
>> Sean O'Dell said:
>> > Use YAML as the control file instead of native Ruby.  I think it would
>> > make automating builds easier.  Ruby is okay when you're hand-crafting,
>> > but it makes automated build creation a little dicey.  Not terribly, but
>> > a little.
>>
>> Actually, the .gemspec file is optional, and I never build one for my
>> projects.  I just use Rake to control the building of the
>> Gem::Specification object directly and then generate the gem from the spec
>> object.  Details can be found here:
>> http://rubygems.rubyforge.org/wiki/wiki.pl?CreateAGemUsingRake
>>
>> If you want to build the spec automatically, but don't want to use Rake
>> (shame on you), just create the Gem::Specification object in your code (as
>> you would in a gemspec file).  To create the gem from the
>> Gem::Spcification, just use:
>>
>>    builder = Gem::Builder.new(spec).build
>>
>> If you want a yaml file out of the process, build the spec and write out
>> the results of spec.to_yaml.

> That sounds like what I need.  Can I re-constitute the YAML into a native Ruby
> data structure and pass it to Gem::Builder.new?

I'm sure you can, but I reckon this sounds like the more difficult way
to do things.  I don't see why building a gem requires run-time
generation of its specification, beyond the package version.  It
should all be known upfront.

What actual difficulty or restriction does a normal .gemspec (or
better yet, a Rakefile gme package task) cause you?

BTW you asked somewhere about seeing detailed information about a gem.
If you have a gem X installed, then try this:

  gem --info X

It will print out the spec in YAML.


>>
>> I will confess that I've read the above several times and am a bit
>> confused.  Are you refering to the process of bundling up the package
>> files in to a gemfile, or  the process where a gem file is installed onto
>> a system.

> Yeah, it's a confusing subject.

> There are two parts of the build process.  Gems has to create a package, and
> the files and directories have to be prepared so Gems can build the package.

I don't do file and directory preparation; but I'm with you so far...

> I like scripting the preparation part myself, and I wanted Gems to just take
> meta data and create the final .gem from it.  From the examples I've seen,
> the .gemspec file (Ruby code) trims out CVS directories and such as part of
> the package creation process.  That means that the part I want to script,
> preparing the files/directories, is spread out into two places: my build
> script and the .gemspec script.

My suggestion: prepare your files and directories for packing; let's
say in a "build" directory.  Have a .gemspec file that anticipates
this structure, and then:

  cd build
  gem -b ../whatever.gemspec
  mv whatever.gem ../packages

> I'd prefer that .gemspec was just static meta data and contained no
> code.  But as I understand it, the .gemspec file is used to create a
> static data structure that Gem::Builder uses, so maybe that point is
> moot.  I think I can load a static YAML file that I generate myself
> and pass it to Gem::Builder.new.

I'll be interested to see how this goes.  I'd be even more interested
to see if there's a reason that YAML generation is better for you.
Whether there is or there isn't, either way there's an opportunity to
document some best practices out of this.

Cheers,
Gavin