From: James Britt <jamesUNDERBARb@...>
Date: 2004-07-30T12:19:23+09:00
Subject: Re: Including other people's Ruby libs in your package

Chad Fowler wrote:
> On Fri, 30 Jul 2004 08:04:25 +0900, James Britt
> <jamesunderbarb@neurogami.com> wrote:
> 
> 
>>For Gems, it might be nice (or feature-creep overkill) to specify that,
>>if a user refuses to install dependency Foo, then fail the installation,
>>but if they refuse pseudo-dependency Bar, that's OK, keep going with a
>>"You're going to miss some good stuff" warning.
>>
>>
> 
> 
> I've had this on the list for a while, but I'm still not sure if it's
> feature creep or a good feature to add.  I have what I think is a
> healthy uneasiness about adding anything to the gem spec, but
> something like this may just find it way in.

An idea I floated on another list (and somewhat off-topic for the main 
discussion there at the time) was having some way to vet code before 
automatically installing it.

Run a set of sanity-check tests over the proposed code (for example, 
look for references to $SAFE, alterations of base classes, 
upgrades/downgrades of existing files, and the use of camelCase for 
method names), then report a score of some sort.

The user can then decide that maybe the installation isn't a good idea, 
or it presents some risk, or would fill the hard drive, and cancel the 
installation.

There have been a number of times I installed Perl code using the CPAN 
shell, astounded by the number of extra libs that were installed as 
dependencies.  I thought I had a new screen saver.

Is there some simple way to plug in additional operations along the 
RubyGems installation process path, such that people can write a class 
and tell RubyGems, "When you get to this step, run this code, passing in 
the directories of the extracted but not-yet-installed gems"?

Then write an XML (oops, I mean YAML) file that defines a customized 
processing path.

Or something.  But then folks who wanted to embark on feeping creaturism 
could have a field day.



James