Yet Another Ruby Packager
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Failed to load latest commit information.



This project hopes to provide a light-weight project management, packaging and distribution system for Ruby libraries.

This project is HIGHLY, HIGHLY experimental. Goals have changed several times throughout the life of this project and probably will several more times.

At the moment, my plan is to create something that borrows (conceptually) from RubyGems, Bundler, Apache Ivy while avoiding some of the things about each that I don't like.


This is just a pet project of mine. It doesn't even function at the moment. However, if you like the general idea and want to contribute code, ideas, or even encouragement, please fork or watch the repo or fire off an email!


The problems I'm trying to solve include:

  • A simple way of modularizing Ruby code and using it in other Ruby projects. RubyGems has some limitations (and some lack of limitations) that make it less than ideal in many environments. Bundler adds some capabilities but inherits some of RubyGems' flaws.

  • A utility that handles projects, dependencies and repositories during development, but is not required during runtime. RubyRap is not intended to be a runtime load_path manager.

  • While I don't envision and hard constraints at the moment for Raps, I would like to encourage certain standards – perhaps through the use of validation messages or something. Soft constraints can include:

  • It would be nice if packages were in a format more conducive to manual manipulation. Java's JAR files are basically just zip files. I'm going to head that direction until I see a good reason not to.

(Soft?) Constraints on Raps

The following (soft?) constraints are designed to help achieve the goals stated above.

  • Library packages must have following layout:

          ... unrestricted ...
    doc (optional)
    spec (optional)
    test (optional)
  • Library naming must use underscores to represent camelcasing, and dots to represent module hierarchies.

    ie:  A library that is primarily based on a module called
         Rack::SuperCoolExtension must be called rack.super_cool_extension.
  • Naming constraints do not necessarily apply to actual module namespacing, though that would be good practice. But it is entirely possible to package up code that pollutes the global namespace or does not follow the naming scheme you might expect from the file layout.

  • A library should not reference files from its own project that exist outside the lib folder.


Brasten Sager