From: Robert Feldt <feldt@...>
Date: 2001-10-30T17:34:51+09:00
Subject: [ruby-talk:23822] Re: RubyGems Status (was: Re: Someinspirations from REBOL)


I have some additional comments below.

On Tue, 30 Oct 2001, Rich Kilmer wrote:

> OK...here's an idea for making a Gem a Ruby executable file...
> 
> What if the file format was a Ruby document like...
> 
So, to make sure we're discussing the same thing, we are discussing the
format for all Gems, right? If possible we should avoid multiple
formats. A gem is a gem is a gem... ;-)

>   require "rubygems" #or whatever ;)
>   include Gem unless kind_of? Gem
> 
>   begin_gem "RichsCoolGem"
> 
>   author="Rich Kilmer"
>   version="1.1.3"
>   requires="RyansCoolGem,0.0.2"
>   requires="RobertsCoolGem,2.0.0"
>   signature="...secure hash/signed..."
>   public_key="...public key..."
>   compression="LZO"
>   encoding="BASE64"
>   executable="myFile1.rb"
> 
>   [FILE=>"myFile1.rb", MIME_TYPE=>"text/ruby", VERSION=>"1.1.1"] = <<_FILE
>   ...BASE64 ENCODED, LZO COMPRESSED FILE...
>   _FILE
>   [FILE=>"myFile2.rb", VERSION=>"1.0.2", COMPRESSION=>"ZLIB"] = <<_FILE
>   ...BASE64 ENCODED, ZLIB COMPRESSED FILE...
>   _FILE
> 
>   end_gem
> 
I think this encoding stuff has some drawbacks. It will add a performance
penalty. I agree that it might not be noticeable and we should avoid
premature optimizations but in the end we want good Ruby performance and
loading is one component in this. This would probably be ok if there was
some added benefit but I can't see it. The only one I can think of is that
you can have different encodings/encryption/compression on different
files. This may be a feature but I think in most cases it won't be.

So I'd propose to stick with something like what I described in
[ruby-talk:22530], ie. a Gem is basically a Ruby object adhering to a
FileArchiveContract. This contract specifies two methods:

files - returns an Array of objects with info for each file in the archive
        (its name with path, size etc)

[](filename) - returns string with uncompressed data in file

If we cant trust Ruby's Marshaling format to be the same for future
versions of Ruby we will have to use something different than a simple
Marshal.load to get the FileArchive object. Probably add a creation method
to the contract above something like

FileArchive.new(files, filedata)

where files is an Array of arrays with the info from files above and
filedata is the binary data of the archive.

By only specifying this contract people can add fancy compression and
whatever in the future simply by adding the uncompress code and the code
for the FileArchive subclass/substitute to the head of the gem.

I think we should specify all of the gem standard in this contract
fashion and then have the standard implementations of Gem, FileArchive and
a basic compressor distributed with Ruby.

The contract for a gem would probably be to support the meta-data
previously discussed and then respond_to? methods like 

inspect          - returns string with human-formatted descirption of gem
                   and its contents
unpack(path)     - unpack the file archive contents to a path, 
make             - unpack and then build any extensions or other setup
                   stuff
install          - unpack, make and then install
do_command(argv) - parse command line and performs the commands given
                   there. (--make will call make etc.)

Comments?

/Robert