Trans wrote:
> 
> Actually, for me it's much more difficult because I mostly write libs
> and not apps. It's not as simple as a single .rb file to require. I
> have a large collection of them, each needs to be requirable. This
> problem arises elsewhere too, for instance, using CodeForPeople's
> traits lib. It's isn't
> 
>   require 'codeforpeople/traits'
> 
> it's
> 
>   require 'traits'
> 
> Effectively CodeForPeople has taken a monopoly on the term 'traits'.
> That might not seem a big deal (and note I'm not worried about the
> particular case, it's just an example), but multiple that by 70 and
> you'd be sitting in my shoes (yes I have 70+ small libs to
> distribute). Multiple that by another factor of 100 or more as Ruby
> becomes an increasingly popular language, and we really have the
> potential for name clash issues.

I guess I should start using a prefix, then. ;)

On the other hand, facets handles that particular problem (lots of 
little things), as does Ruby (stdlib!).

Without deeper knowledge of your libs, I've come up with this example:

RubyForge Project: TransLibs

Packages:
tl_network (required as "network/lib1", "network/lib2" etc..
tl_administration (required as "administration/lib1", 
"administration/lib2etc.)

And to prevent it completely, you could add a prefix. Or you could just 
leverage rubygems, so that require "net/translib1" works, for example.

But yes, the namespace is limited, but OTOH, it is the developer's 
responsibility to anticipate these problems, and prevent them. But 
upsetting an established package management is a bit of overkill, IMHO.

> Fair enough. But I guess I'm really asking, if it should. Maybe we'd
> be better off if it did?

I have no clue how easy such a mini-fork would be, or if it is necessary 
to do so. My gut instinct says, that it'd be counterproductive, as 
SourceForge, RubyForge, JoomlaForge and JasperForge all use that naming 
convention. And making "RubyForge" special, because the naming is a 
little bit off, and causing confusion for those who switch their project 
away from SourceForge, or deploy their future ruby apps/libs on 
RubyForge together with SourceForge would create a lot more confusion, IMO.

-- 
Phillip "CynicalRyan" Gawlowski
http://cynicalryan.110mb.com/
http://clothred.rubyforge.org

Rule of Open-Source Programming #1:

Don't whine unless you are going to implement it yourself.