[Rubygems-developers] Config clash

Gavin Sinclair gsinclair at soyabean.com.au
Wed Sep 15 07:29:45 EDT 2004

> On Wed, Sep 15, 2004 at 12:03:33AM -0400, Richard Kilmer wrote:
>> >> On Tue, 14 Sep 2004 22:33:09 -0400 (EDT), Gavin Sinclair
>> >> <gsinclair at soyabean.com.au> wrote:
>> >>> I've just dicovered an anti-social behaviour of RubyGems.  I'm
>> mucking around with 'acoc' (look on RAA).  It defines a class
>> called Config:
>> >>
>> >> mmm. I think that this is really a problem with acoc. It is still
>> developed (last update 2004/04/05). acoc shouldn't be creating a
>> class "Config", it should be doing something like:
>> >>
>> >> module Acoc
>> >>   class Config < Hash; end
>> >>   :
>> >>   : # The rest of the Acoc module.
>> >> end
>> >>
>> >> exit Acoc.run(...)
>> >>
>> >> This is the sort of thing that RPA will be good at handling.
>> And now so is gems...
> I think he meant by patching the original sources and submitting the
> modifications to the author.
> My first reaction was "definitely acoc's fault", but on second thought,
> if it's meant to be stand-alone (and not built upon), it is not *that*
> unreasonable to pollute the global namespace.

I agree.  I'm wasn't actually trying to build upon it.  I was trying to
debug it with my dev-utils gem (to be released after RG 0.8).  That's when
I struck the problem.  An odd case, but nice to avoid it in future.

> Anyway with rpa-base this
> sort of collisions will not happen (at least for some time) because no
> RPA-specific code is required to run/load apps installed with rpa-base,
> by default; i.o.w. you can do  rpa remove rpa-base  and the installed
> ports will still work. You could approximate that with 'heavy stubs'
> written carefully to avoid depending on RubyGems, but there's probably
> little gain in that.

Agreed.  We've found the right balance now, I think.  RubyGems is
obviously going to use some stdlib stuff.  We'd be justified in putting
Config into the global namespace, but since it's such an abberation (i.e.
Ruby's Config should really be named something else) then it's nice to
avoid clashes if possible.


More information about the Rubygems-developers mailing list