On Apr 19, 3:51 pm, Phillip Gawlowski <cmdjackr... / googlemail.com>
wrote:
> 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.)

I would put these down as bad practice. If the package is called
tl_network, then my "ownership" of the lib namespace is tl_network.
and that's where the require should be, eg. require 'tl_network/lib1'.
Of course that would lead me too 'tl/network/lib1' instead, hence the
project is finding it's way in to the name regardless.

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

Potentially dangerous?

> 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.

I agree. Though I'm not sure how "established" it is. It's seems more
haphazard/organically home-grown ;-)

> > 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.

Oh, I actually meant a standard means of require. For instance, we
always should use:

  require 'myproject/mypackage/mylib'

We could still "fight" over shortcuts, ie.

  require 'mylib'

where mylib.rb would just contain a secondary require to the long
name, but at least we'd always have a fall back in case of a conflict.

T.