Rubygems thoughts

That's fantastic. Some other suggestions:

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.

Also, it would make it easier for third-parties to display information about
Gems. Right now, Rubyforge doesn't list much information about the Ruby Gems
available, it only lists file names. It could easily extract a YAML file and
print the gem title, description, etc.

I think Gems right now handles a little of the build process, but I have to
tell you from experience, it doesn't handle everything, so my Gems build
process is a hodge-podge of me partially creating the directory structure
with some scripts, and then Gems seems to do some work of its own, adding
directories according to the delete_if call. Perhaps Gems shouldn't do any
building at all; perhaps it should be more like Debian apt where all it does
is bundle what you tell it to using a control file with meta information.

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 hope that made sense. It seems like a lot to ask for, but it should
eliminate a whole lot of code surrounding the gem build process. If what I'm
thinking came out right, it should amount to more control to the developers,
less work for you guys and good meta information for everyone.

  Sean O'Dell

···

On Thursday 24 June 2004 10:48, Jim Weirich wrote:

Jim Weirich said:

<nothing!>

I hate it when I hit send by accident!

> Sean O'Dell said:
>> I didn't realize this either. Someone ought to write a definitive
>> tutorial on Gems and maintain it with each release. The examples
>> I found left a lot of things unexplained and it was a painful
>> session of trial-and-error to get my gems working properly, and
>> even then, I didn't know there was a way to bypass the "require_gem"
>> statement.
>>
>> If any more work is done on Gems, I strongly recommend it be on good
>> documentation, and then maintain those docs to update it for the changes
>> made in the future.

We are currently reworking the command structure of the gem command. It
grew to be a confusing hodge-podge of options and suboptions. The new gem
command will follow the cvs model (e.g. gem install ...) and the options
will be clearly identified for each gem command. The internals will be
much cleaner as well.

At that time we will revisit the documentation and make sure it gets
updated. Documentation is high on our priority list.

Thanks for the feedback.

Hey, at least you didn't accidently send a love letter for your wife to the
ML.

  Sean O'Dell

···

On Thursday 24 June 2004 10:48, Jim Weirich wrote:

Jim Weirich said:

<nothing!>

I hate it when I hit send by accident!

While vacationing in Europe, I'm working on what will hopefully be a
very thorough and friendly guide to using RubyGems. Hopefully I'll be
able to share more when I get back.

Sorry for not being personally more responsive to RubyGems
questions/issues over the past week or so. I've been traveling with
family...supposed to be on vacation. :wink:

Thankfully, there are a lot of knowledgable RubyGems people, so even
with two of us out of town on vacation work continues (perhaps even
better without us...what do you think Jim? :wink:

Chad

···

On Fri, 25 Jun 2004 02:48:59 +0900, Jim Weirich <jim@weirichhouse.org> wrote:

Jim Weirich said:

<nothing!>

I hate it when I hit send by accident!

> Sean O'Dell said:
>> I didn't realize this either. Someone ought to write a definitive
>> tutorial on Gems and maintain it with each release. The examples
>> I found left a lot of things unexplained and it was a painful
>> session of trial-and-error to get my gems working properly, and
>> even then, I didn't know there was a way to bypass the "require_gem"
>> statement.
>>
>> If any more work is done on Gems, I strongly recommend it be on good
>> documentation, and then maintain those docs to update it for the changes
>> made in the future.

We are currently reworking the command structure of the gem command. It
grew to be a confusing hodge-podge of options and suboptions. The new gem
command will follow the cvs model (e.g. gem install ...) and the options
will be clearly identified for each gem command. The internals will be
much cleaner as well.

At that time we will revisit the documentation and make sure it gets
updated. Documentation is high on our priority list.

Thanks for the feedback.

This sort of centralized system is the easiest solution (I'm soon
implementing it :), but it requires that the repository maintainers
actively monitor the packages they accept, to make sure they're not
distributing trojans. RubyGems is built on the idea that upstream
developers should do the packaging themselves [1]: RubyGems' developers
only hack the installer itself, they're not responsible for the gems
distributed from their repos.

Some more info about the advantages of having a 3rd party packaging team
can be found at http://rpa-base.rubyforge.org/wiki/wiki.cgi?Rpa_FAQ .

(1) and implicitly that all gems out there are OK (that is, packaged
correctly and non-malicious), since there's no control/QA process.

···

On Fri, Jun 25, 2004 at 02:00:36PM +0900, Lennon Day-Reynolds wrote:

If the SHA hashes for each gem are part of the repository
listing and URL at which it is downloaded, and the package listing
file is signed by the repository administrator(s), then you can have a
fairly secure distribution channel without a complex "web of trust".
Just get the (presumably well-known and mirrored all over the place)
public key for a repository, and you can download any package you like
from it without much worry over tampering.

--
Running Debian GNU/Linux Sid (unstable)
batsman dot geo at yahoo dot com

* SynrG notes that the number of configuration questions to answer in sendmail
  is NON-TRIVIAL
  -- Seen on #Debian

Lennon Day-Reynolds wrote:

As a temporary fix, why not have the URLs at which gems can be
downloaded be derived from a secure hash (i.e., SHA digest) of the
file? It doesn't guarantee that your downloaded gem listing hasn't
been affected, but at least a given URL, once distributed as the
download location, can easily be checked -- if the actual hash of the
downloaded gem is the same as the hash component of the URL, you know
that the version you downloaded is the one advertised.

Going further, imagine a system with multiple repositories that
aggregate some reasonable number of packages -- let's say that
ruby-lang.org, rubyforge.org, and sourceforge.net all have public
package repositories set up, with a single public key for each
repository. If the SHA hashes for each gem are part of the repository
listing and URL at which it is downloaded, and the package listing
file is signed by the repository administrator(s), then you can have a
fairly secure distribution channel without a complex "web of trust".
Just get the (presumably well-known and mirrored all over the place)
public key for a repository, and you can download any package you like
from it without much worry over tampering.

Anyone see any obvious attacks or holes?

As Mauricio said, a centralized system like you propose requires the repository to validate the packages. That almost always results in a bottleneck at the repository level. Just look at Debian. The packages are done by lots of volunteers, and let's assume we have enough volunteers to package the interesting programs. Why is Debian notoriously slow at releasing? Because of the stress on quality which boils down to some QA on the quality of the packages and distribution. I, for one, am happy running testing which is the same model without the repository bottleneck.

So if we want to avoid repository maintainer bottleneck, we want to make the developers (or gems packagers if they're different people) responsible for signing the package, if it is to be signed at all. The repository could automatically check signatures and add its own signature which gives us the benefit you mentioned.

A strong assurance that the package came from the maintainer can be had if you have a web of trust. Most people aren't that paranoid though, and they're happy with verifying that the hash matches what's on the website. I for one am less concerned with the repository getting hacked (that's likely to be noticed before I get bitten by it even if happens), than with someone taking advantage of an unprotected upload scheme.

It would be nice if Gems also used the directory structure used by setup.rb;
it works well and is very friendly with C extensions. It would be nice if
Gems used the same exact layout so I didn't have to script two completely
different layouts for setup.rb and then for Gems.

It would also be nice if Gems weren't just for Ruby libraries, but an
operating-system-independent distribution system.

  Sean O'Dell

···

On Thursday 24 June 2004 11:24, Chad Fowler wrote:

On Fri, 25 Jun 2004 02:48:59 +0900, Jim Weirich <jim@weirichhouse.org> wrote:
> Jim Weirich said:
>
> <nothing!>
>
> I hate it when I hit send by accident!
>
> > Sean O'Dell said:
> >> I didn't realize this either. Someone ought to write a definitive
> >> tutorial on Gems and maintain it with each release. The examples
> >> I found left a lot of things unexplained and it was a painful
> >> session of trial-and-error to get my gems working properly, and
> >> even then, I didn't know there was a way to bypass the "require_gem"
> >> statement.
> >>
> >> If any more work is done on Gems, I strongly recommend it be on good
> >> documentation, and then maintain those docs to update it for the
> >> changes made in the future.
>
> We are currently reworking the command structure of the gem command. It
> grew to be a confusing hodge-podge of options and suboptions. The new
> gem command will follow the cvs model (e.g. gem install ...) and the
> options will be clearly identified for each gem command. The internals
> will be much cleaner as well.
>
> At that time we will revisit the documentation and make sure it gets
> updated. Documentation is high on our priority list.
>
> Thanks for the feedback.

While vacationing in Europe, I'm working on what will hopefully be a
very thorough and friendly guide to using RubyGems. Hopefully I'll be
able to share more when I get back.

Sorry for not being personally more responsive to RubyGems
questions/issues over the past week or so. I've been traveling with
family...supposed to be on vacation. :wink:

Thankfully, there are a lot of knowledgable RubyGems people, so even
with two of us out of town on vacation work continues (perhaps even
better without us...what do you think Jim? :wink:

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.

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.

I think Gems right now handles a little of the build process, but I have
to tell you from experience, it doesn't handle everything, so my Gems
build process is a hodge-podge of me partially creating the directory
structure with some scripts, and then Gems seems to do some work of its
own, adding directories according to the delete_if call. Perhaps Gems
shouldn't do any building at all; perhaps it should be more like Debian
apt where all it does is bundle what you tell it to using a control file
with meta information.

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 hope that made sense. It seems like a lot to ask for, but it should
eliminate a whole lot of code surrounding the gem build process. If what
I'm thinking came out right, it should amount to more control to the
developers, less work for you guys and good meta information for everyone.

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.

I think it is the former, but then I'm not sure what part of the build
process you think gem performs. I am not aware of any directories added
by the "gem -b" command. Could you give an example?

And again, thanks for the feedback.

···

--
-- Jim Weirich jim@weirichhouse.org http://onestepback.org
-----------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct,
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)

Why not just use the public-key system already build into SSH/SCP/SFTP
to authenticate the package maintainers' uploads? Since presumably
each repository would have some sort of access controls on uploads,
you could just require each new contributor to generate a key for
access to the repository, and transfer it to the administrator(s) for
installation on the hosting system. Then, SFTP transfers become
password-less for the packager, (since their key is already installed
on the hosting machine) while still authenticating each upload.

Signing each package, while valuable in term of ensuring maximum
security, could also be just as significant a bottleneck for adoption
and use of packages due to the need to acquire and trust a potentially
large number of public keys (i.e., one per author). Building effective
public key infrastructure has been tried many times before, and while
there are some small groups in which it works, many more have found
that the effort required to induct new members into the "web of
trust," or even to adjust to normal occurances like lost keys, simply
made it too difficult to maintain.

It's not that I'm trying to say that PKI is a bad idea; personally, I
wish that everyone I knew had PGP keys, and that signing, at least (if
not outright encrypting) personal communications and documents were
just considered standard practice. Unfortunately, even among the more
tech-savvy people I know, tools like standard FTP and unencrypted
webmail access are all too common.

I also want to make the repository admin's job as easy as possible,
but having that single key for the repository, rather than one for
every package author, greatly simplifies the key management for
end-users. In reducing the number of keys that have to be verified and
stored, it also could make the entire system more, rather than less,
secure, as the chances of getting a fake key for one of the the main
repositories would be greatly reduced by their increased profile.
Major, coordinated efforts would be necessary to alter the keys of any
major repository, as it could be easily mirrored at any number of
locations for verification.

Lennon

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

···

On Thursday 24 June 2004 14:01, Jim Weirich wrote:

> 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 hope that made sense. It seems like a lot to ask for, but it should
> eliminate a whole lot of code surrounding the gem build process. If what
> I'm thinking came out right, it should amount to more control to the
> developers, less work for you guys and good meta information for everyone.

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.

I think he's referring to a 2-stage install, like the one in FreeBSD's
ports or Debian (incidentally, that's what rpa-base does too), where
during the package build phase the things to be installed are placed
under a temp. directory, which is then packed into the "binary"
package. Installation involves then unpacking the later under some prefix.

The main advantage compared to Rubygems' current behavior is that you
can relocate files, etc...

I think it is the former, but then I'm not sure what part of the build
process you think gem performs. I am not aware of any directories added
by the "gem -b" command. Could you give an example?

Currently this sort of things have to be handled externally to RubyGems
(for instance with Rake), since it can at most reject some of the files
in the sourcedir when building the gem, i.e. it works like
tar --exclude .... cf

···

On Fri, Jun 25, 2004 at 06:01:52AM +0900, Jim Weirich wrote:

--
Running Debian GNU/Linux Sid (unstable)
batsman dot geo at yahoo dot com

'Mounten' wird für drei Dinge benutzt: 'Aufsitzen' auf Pferde, 'einklinken'
von Festplatten in Dateisysteme, und, nun, 'besteigen' beim Sex.
  -- Christa Keil

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

···

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

On Thursday 24 June 2004 14:01, Jim Weirich wrote:

Sean O'Dell wrote:

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?

Yes.

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.

There's nothing stopping you. The examples you have seen are building the gem from directly from CVS working directory and filter out the stuff they don't want. If you build a pristine directory with no extraneous files (which I do for tar and zip packages), then your file list in the gemspec can just be Dir["**/*"]. No need to filter out stuff in the gemspec if your scripts have done it for you.

  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 think everything is there that you need. Have fun.

···

--
-- Jim Weirich jim@weirichhouse.org http://onestepback.org
-----------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct,
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)

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

I agree, but I don't mind having to call a little code to load my own YAML and
create the final .gem. If Gems had the ability to build directly from a YAML
config file, that would be nice, but it's good enough for me being able to
call Gem::Builder.new(spec) where spec is a data structure I just loaded from
YAML. It's only 2 calls, and I'd make them from my build-generating script
anyway, so I don't mind.

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

It's native Ruby code, and since I generate the .gemspec file with code, I'd
prefer I was generating something with more "rules" like YAML, and that I
could use the result elsewhere (like merging spec data into a web page or
whatever).

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.

That works pretty much, if I can call that on any .gem file. I was thinking
not so much of using the YAML data for human-reading as much as automatically
pumping into other things, like web pages, or a database or whatever.

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

Well, two places it would be useful. One, if the YAML file could be extracted
from the .gem file (which I think gem --info X does) then you can merge the
information into web pages and such (think of a richer gem download web page
at Rubyforge). Third-party version systems would be possible, etc. The
other is, pre-build-time. As a developer, say I take my .gemspec file which
is normally used only by Gems and I ssh it up to a web site somewhere, which
dynamically merges the information in the .gemspec with a web page to show
everyone visiting the current version, the dependencies and so on. You could
even generate a script that loads the YAML and contacts RAA and updates your
RAA entry with all the latest information.

Also, and this is a little mystic perhaps, I find that simply using YAML
whenever I can opens doors to doing other things I don't initially imagine.

  Sean O'Dell

···

On Thursday 24 June 2004 15:29, Gavin Sinclair wrote:

On Friday, June 25, 2004, 8:07:45 AM, Sean wrote:
> On Thursday 24 June 2004 14:01, Jim Weirich wrote:

Sounds like it! When you guys update the documentation, be sure to make a
short section for do-it-yourself'ers showing the Gem::Builder.new trick. The
fact that Gems can already work with a data structure loaded from YAML is a
level of flexibility that's not readily apparent.

  Sean O'Dell

···

On Thursday 24 June 2004 18:18, Jim Weirich wrote:

Sean O'Dell wrote:
>>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?

Yes.

  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 think everything is there that you need. Have fun.