From: Barry Hanna <barryahanna@...>
Date: 2007-11-05T04:43:22+09:00
Subject: Re: This is how we Roll

------=_Part_20298_24823940.1194205399868
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

unsubscribe

On 04/11/2007, Trans <transfire@gmail.com> wrote:
>
> 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.
>
>
>

------=_Part_20298_24823940.1194205399868--