Rubyrap is a project mainly written in Ruby, it's free.
Yet Another Ruby Packager
== \RubyRap
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.
== WARNING
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!
== Goals
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:
Raps should be able to co-exist with each other in the same load path!
To that end, I'm STRONGLY in favor of the practice laid out in the following post by Yehuda Katz:
http://yehudakatz.com/2009/06/15/rubygems-problems-and-proposed-solutions
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: Rapfile lib
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.
=== Authors
Brasten Sager [email protected]