[Rubygems-developers] New Gem format?

Mauricio Fernández batsman.geo at yahoo.com
Wed Jul 28 06:52:40 EDT 2004


On Wed, Jul 28, 2004 at 11:18:12AM +0200, Michael Neumann wrote:
> Hi,
> 
> Are there any news on this? Last night, I wrote a simple script that can 
> create tar files (and cpio) in pure Ruby. It would be simple to create 
> tar.gz, just feed it though Zlib.

The code for the new format was accepted and committed a couple weeks
ago, see
http://rubyforge.org/pipermail/rubygems-developers/2004-July/000759.html .

I have been using that code for a while and it's been reported to work
OK on win32, OSX, Linux, FreeBSD & Dragonfly.

> It would be nice to be able to release one file, which serves both as a 
> gem and as a tar.gz. So, you have your "gem build" command, upload the 
> resulting file, and that's it. Except that people will not recognize a 
> .gem file as a .tar.gz file, and it's not nice to upload two identical 
> files to rubyforge.org, which only differ in it's ending.

The new format is not only a tarball, but rather a tar archive containing
a compressed tarball with the data itself and gzipped metadata (see the
link above for the details).

> BTW, it would be nice, if rubygems would be able to construct a 
> "install.rb" file from the gemspec. Shoulndn't be too hard. This way it 
> would be very simple to distribute a package as both a gem and a tar.gz ;-)

IMHO gems and "pristine" tarballs should remain as two separate things.
The sources in the .tar.gz are more general in the sense that they
always include everything, whereas the .gem need not (otherwise the
files field in the gemspec is redundant).
As for constructing the install.rb from the gemspec, it doesn't make
sense if the resulting installer is going to depend on RubyGems and just
unpack the tarball into the gemdir. The package remains 'gemified',
which makes the task of external packagers (FreeBSD, Debian, RPA?)
harder, and the install.rb is just gem in disguise; it buys you very
little now that the .gem format is not as opaque as it used to be.

As a side note, concerning the latter: it should be made clear that 
  require 'rubygems'
  require_gem "foo"
offers no advantage vs
  require 'foo'
now that stubs are created by default. 

I've never found a 'qualified' (e.g. require_gem 'foo', ">1.0")
require_gem in the wild, which is the only case where it makes sense.

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

Q: What's the big deal about rm, I have been deleting stuff for years?  And 
   never lost anything.. oops!
A: ...
	-- From the Frequently Unasked Questions


More information about the Rubygems-developers mailing list