About the Ruby Production Archive (RPA)

RPA was meant to be a controlled repository of Ruby libraries and applications, managed by a dedicated team that would ensure consistency and proper QA.

• The Manifesto.
• FAQ

In 2004, over 150 libraries and applications had been packaged for RPA.

A considerable amount of information was gathered in this wiki. Unfortunately, some was lost as a result of massive spamming, but some nodes have been recovered: AllNodes.

Some selected nodes:

• DeveloperChecklist
• WebFrameworks
• PhrogzsWebFrameworksList
• PackageAdvisor
• PackagingNitpickChecklist
• HypotheticalRubyLayout
• GUIComparisonChart
• GoodAPIDesign
• Rails Usage (for historical purposes): using Rails installed through RPA back in 2004, predating the first official packages (in RubyGems? format)

rpa-base: RPA's port/package manager

rpa-base is a port/package manager created to be the base for RPA's client-side package management. You can think of it as RPA's apt-get + dpkg.

rpa-base is very powerful, featuring atomic (de)installs, extensible installation procedures, strong dependency checking (reverse dependency tracking, build-only dependencies), extension support, rdoc/ri integration...

You can see rpa-base in action Rpa Base In Action.

Download

You can get it from http://rubyforge.org/frs/?group_id=265. If you're using Debian GNU/Linux, please read Installing Rpa On Debian.

Features

rpa-base features the following:

modular, extensible design

the 2-phase install is similar to FreeBSD and Debian's package creation; rpa-base packages need not be restricted to installing everything under a single directory ("1 package, 1 dir" paradigm); this will be useful when we define the RPA Policy

strong dependency management

rpa-base installs dependencies as needed, keeps track of reverse dependencies on uninstall, and will remove no longer needed dependencies (e.g. you install A, which depends on B, so B gets installed and then A; when you later remove A, rpa-base will realize B is not longer needed and remove it too).

atomic (de)installs

operations on the local RPA installation are atomic transactions; the system has been designed to survive ruby crashes (OS crashes too on POSIX systems), which means that either a port is installed/removed successfully or the system rolls back to the previous clean state

handling C extensions

if you have the required C toolchain, rpa-base can compile extensions as needed

API safety

all libraries within a RPA release will be guaranteed to be API-compatible; by tying your local applications to specific versions of RPA, they're protected from API breakage. You'll be able to install several RPA releases simultaneously without problems.

rdoc integration

RDoc documentation for libraries is generated at install time (currently put in $prefix/share/doc/rpa0.0/portname)

unit testing

when a library is installed, its unit tests are run; the installation is canceled if they don't pass

ri integration

ri data files are generated for all the libraries managed by RPA; you can access this information with ri-rpa