[Rubygems-developers] gem format

Gavin Sinclair gsinclair at soyabean.com.au
Wed Jul 7 18:39:15 EDT 2004

On Thursday, July 8, 2004, 6:32:16 AM, Chad wrote:

> Hello All,

>   I had a nice chat with Mauricio last night, wherein he suggested that we
> migrate the gem format to tar/gzip instead of the Ruby/YAML/Base64 thing
> we've got now.  He also graciously volunteered to contribute his code from
> rpa-base to enable this.

>   I'm starting to like the idea, myself.  Originally, I liked the idea of
> gems being Ruby files, primarily so that we could actually "run" them for
> installation.  In practice, however, I'm not finding myself doing this.
> And, I don't think we've done much updating of the functionality, since
> we're focused primarily on the gem command.  My educated guess is that
> most RubyGems users are and will usually use remote installation as
> opposed to separately downloading gems and installing them.

Agreed.  And even when I do install a local gem, I most certainly do
not run it directly.  Last I checked, that doesn't do testing or

>   There are obvious advantages to using tar/gzip, including the fact that
> many tools already support it.  I think it would be especially nice for
> browsing the contents of a gem before installing it.

>   Can anyone think of any other reasons *not* to switch?

I like the fact that in the current format, you can examine the
gemspec directly.  I suppose that would be possible in a tarball if
the spec was its own file.

Other than that, no.  The data itself (spec aside) is inscrutable, so
no gain there.  And compression would be handy, I think.

>   I think it should be a very clean thing to integrate.  In fact, a new
> format.rb file would do the trick, replacing the implementation of the
> Gem::Format class.  Nothing else should have to change if it was done
> right.

> Further thoughts?  I know it's kind of a big change, but it actually
> shouldn't affect the users of RubyGems much (other than the need to
> convert old-style gems to the new format--scriptable, of course).

Yeah, I guess go ahead <shrug>


More information about the Rubygems-developers mailing list