RCR 30: Add the ability of Ruby to load extensions (.rb, .so, etc) from .zip files
submitted by Rich_Kilmer on 2001-08-27 01:21:57
This is a legacy RCR. If this is your RCR, please resubmit it using the new format and process.
From a distribution prospective, it would be nice to allow Ruby to have a list of .zip (or .jar - Java Archive format) files that it searches for extensions to load instead of the file system. Although the file system is great for development purposes, you could reduce a Ruby distribution to a dozen files (or less) if you zipped the lib directory. It would also decrease the size of the distribution. I used winzip ("normal" mode) and compressed the 1.6 lib directory(s) (mingw32 distro). It went from 1.2MB to 347KB. This would allow those distributing applications on Ruby to package their entire application code into a single file as well. Jar/Zip was a great feature when added to Java...and I believe it would serve the same benefit for Ruby.
Vote for this RCR
Add comments here
Dave Thomas posted in March. It's (a proof of concept for) the beginnings of what you're talking about.
<br>
Also see . This system will (I believe) also include similar packaging capabilities. Ryan promises he'll release something soon. :)
As Chad says, it seems that RubyGems does most of what you want. The Java jar file system was actually one of the inspirations for RubyGems, along with Dave Thomas' Scarf prototype.
But I've also added something more, metadata, which is information about a package embedded within the package file itself, such as a name, category, dependencies, etc. This idea comes in some ways from the various Linux packaging systems, and is used in the context of code in Microsoft's new .NET system.
The main purpose of this metadata is to allow for an easy to use library distribution system, which is part of "Phase 2" of RubyGems. Phase 1, the core system, will be released within the next week. This core system will allow you to create these RubyGems archive files in two different file formats (binary and plain text), and perform various operations on pre-existing archive files, including of course transparently requiring and loading Ruby source files from within them.
The current file formats use no compression, but I have begun work on a pure Ruby implementation of the Deflate compression algorithm, which could be used in a new "zip" file format for RubyGems. New file formats can easily be created and added into the system without affecting other formats or files already created.
Of course, having the Deflate algorithm written in C and part of the Ruby distribution would be nice, but I'm not sure if it warrents an RCR...
-- Ryan Leavengood
There is already a for Ruby which includes the deflate algorithm. I was going to start playing with it to start on what it seems you are already doing...
I will be looking forward to your RubyGems release (phase 1)
Q: Can the standard libraries also be packaged as a Gem?
--Rich Kilmer
Yes, using the already written zlib and Ruby bindings would certainly reduce effort and would run faster than a pure Ruby implementation, but there are also drawbacks to its use. It obviously requires that zlib itself and its header files be on the machine your installing on, which isn't necessarily assured, even on Unix machines (for instance my Debian box didn't have the header files.) And even though zlib is very portable from what I understand, it probably isn't as portable as pure Ruby code. Another interesting point is that even though the zlib C source is reams of code, so far my pure Ruby version is only a couple hundred lines, including CRC and adler32 code, as well as handling for the gzip and zlib file formats. All I need is to get the deflate algorithm working and it will be done. I'm just having a little trouble with some of the bit manipulation and properly reading the deflate stream.
Regarding packaging the standard libraries as gems, yes it is theoretically possible, excluding any libraries that the core RubyGems system needs (in that case it is sort of a chicken-before-the-egg type problem.) But so far I've only use singleton, which could be removed, leaving no dependencies except for built-in Ruby classes of course and also RubyUnit for testing (which could also be packaged as a Gem...I think.) So that might be an interesting option in the future, and would allow the standard libraries to be under the control of the future RubyGems distribution system, which would allow for easy bug fixes and upgrades without having to reinstall Ruby, manually copy files or apply patches, etc.
Of course before that can happen, RubyGems itself would also need to become a standard library included with Ruby. I'm fine with that :) But in the long run it is up to matz and the Ruby community to decide.
--Ryan Leavengood
I just wrote a basic implementation of this as part of rubyzip. I haven't made a release including it yet, but you can take a look at ziprequire.rb in CVS at
It is a great idea, but why only 'require' from this files? I think the can be useful use this files to store some preferences, images, etc..
It can be used also to include all program sources and resources and attach this to an executable like tcl 'freewrap' program does.
Back to RCRchive.
RCR Submission page and RCRchive powered by Ruby, Apache, RuWiki (modified), and RubLog
Also see . This system will (I believe) also include similar packaging capabilities. Ryan promises he'll release something soon. :)