From: Trans <transfire@...>
Date: 2007-11-05T03:04:18+09:00
Subject: This is how we Roll

Hi--

I've decide to go ahead and announce Roll(s) today. Even though the
code still needs fine-tuning and the docs aren't completely up to
date, I've been using it productively for the last few weeks. So I
figure it's probably a good time being the end of RubyConf --it will
give the lucky attendees something interesting to come home to.

Note, the project is called "Roll", but that doesn't always sound
right in a sentence, so I call it 'Rolls' too, whenever that fits
better.

Okay. So what is it? Roll is a library manager. What it does is
provide an OOP interface to Ruby libs/apps. So you can do things like
this:

  facets = library('facets')
  facets.version #=> "2.0.4"
  facets.require 'functor'

You can also specify versions:

  facets = library('facets', "= 2.0.3")
  facets.version #=> "2.0.3"
  facets.require 'functor'

Of course, in common use, you probably would just do:

  require 'facets:functor'

And for backward/non-roll compatibility (though lookup is less
efficient):

  require 'facets/functor'

That's really the main of the code side of Roll. Pretty simple. It's
really just the loading of libs you're used to with some enhancements,
like versioning and prevention of file name clashing (with Rolls there
is always a way to get to a file).

The big advantage of Rolls plays out on the file system. Rolls can use
your development repositories as-is. There is no need to go through an
installation phase every time you make a change to you lib/app. This
can save a developer a lot of time. It also means that Ruby software
can be "installed" just by dropping a copy of a repository into a
location Rolls knows about --no need to create a specialized package.
For instance just doing an 'svn co', will effectively "install" a
project that's "ready-to-roll".

An important thing to understand is that Roll is not a package
manager. It does not download packages, resolved dependencies and
install them. Rolls is _library manager_ which is _package format
neutral_. It can work with any of them. However, it also largely
mitigates the need for specialized package formats --at least as far
as Ruby libs go, b/c a snapshot of a developers repo (minus anything
you don't want to distribute of course) would do just as well. As
such, it represents the first important piece in my overall strategy
for creating a near "zero-install" system for Ruby.

Alright, that's the super brief explanation. Like I said, there's
still work to do -- such as Windows bin/ support, and how best to
handle libs with c extensions. But it's coming along nicely. Anyone
who is interested in helping, just drop me a line.

  http://roll.rubyforge.org

T.