From: Sean O'Dell <sean@...>
Date: 2004-06-25T07:07:45+09:00
Subject: Re: rubygems thoughts

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?

> > Also, it would make it easier for third-parties to display information
> > about Gems.
>
> The spec is actually encoded in the gem as a Yaml structure.  Extracting
> that yaml structure is about 5 lines of code, but it would be nice if
> there was library support for that (and there might be, I'm not sure).
> I'll look into that.

You could prepend the .gem file with all the meta information as a YAML 
document, so code to load it could be:

specinfo = YAML::load(File::readlines("library.gem").join)

> > Leaving the build process to the developers seems natural to me, and it
> > would make your (Gems developers) job easier and more clear.  All you
> > would have to do it install what the control file tells you to.  Let the
> > developers create their directories in the way they want, and generate
> > the control  file, Gems could just bundle it all up and handle the
> > distribution tasks (download, install, uninstall, etc.).
>
> 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 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.  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.

	Sean O'Dell