[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ruby-talk
Subject:    Re: [ANN] Non-standard library project
From:       James Britt <jamesUNDERBARb () neurogami ! com>
Date:       2004-06-14 15:59:55
Message-ID: 40CDCBCD.6080704 () neurogami ! com
[Download RAW message or body]

Gavin Sinclair wrote:

> Hi all,
> 
> It's a bit cheeky to call this an announcement, since it's only
> announcing a project idea.
> 
> I would like to create a RubyForge project that builds a library of
> useful classes and modules.  That basically describes the standard
> library.  This library wouldn't be standard, hence the name
> "non-standard library".
> 
> The purposes of the project:
> 
>  * collect existing small projects (e.g. Memoize) to ensure their
>    continued maintenance, and hopefully give them higher exposure

Would these be projects that have reached the end of their development 
(i.e., they're  "done")?

> 
>  * provide a good environment for the development of ADTs, etc.
>    that might otherwise not seem worthwhile due to project
>    management overhead

What's ADT?

> 
>  * provide a rich library that is easy to install and has a high
>    standard of documentation and testing

Does rich === large? :)

> 
>    * thus, convenience and quality


A concern:  n different libraries have ~n owners. How is project 
access/admin handled through RubyForge?

Why is this better than having a separate project for each library?  Is 
it that much harder to create a new project than it is to get a project 
added to the NSL?


> 
> For example, a very recent thread suggested *replacing* pack and
> unpack with an OO version (Packer and Unpacker classes).  That's a
> radical suggestion that's unlikely to be accepted.  The milder
> approach of providing an OO facade to the existing methods is more
> reasonable, but if accepted, would still take a long time to appear in
> a Ruby release.
> 
> On the other hand, inclusion of this idea in a 'nonstdlib' project
> would be feasible and fast.  Before long, you could write in your
> code something like this:
> 
>   require_gem 'nonstdlib', '>= 0.3'

Another concern (playing Devil's advocate here):  How is this different 
from

   require_gem 'kitchen_sink_plus_more', '>= 0.3'

I think I would prefer to install those libs I expect I'll need, rather 
use bulk packaging.

I agree, though, that there is the matter of small, useful libs 
disappearing over time from owner attrition( I'm finding this to be the 
case with the sysvipc lib), but I'm not convinced about arbitrary bundling.


James


[prev in list] [next in list] [prev in thread] [next in thread]