From: Phillip Gawlowski <cmdjackryan@...>
Date: 2007-04-20T06:41:22+09:00
Subject: Re: Project vs. Package

Trans wrote:
> 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.

I don't see the problem with the project in the namespace. If we take 
Rubyforge as a standard, your project will always be unique (as the 
project you register is a UNIX name, and is as such unique already), and 
nobody using RubyForge will have the same problem.

And even so, you don't have to use the project name in the package, but 
it is convenient to do so, as most searches, probably, take at least the 
name of your gem as starting point.

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

The latter can be, depending on much the stdlib is changed. But since 
RubyGems adds your gem's path to $LOAD_PATH, you are pretty safe.

>> 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 ;-)

The same can be said about apt. ;)
But I'm sure that RubyGems is pretty much a standard within the Ruby 
community. That being said, most established solutions are more or less 
born out of necessity.

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

I disagree, as it would greatly influence how collaborative efforts or 
"umbrella" projects like seattle.rb would have to do their job. Besides: 
The early bird gets the worm. This kind of "namespace" conflict will 
always arise, in many areas (just take a look at trademarks, for 
example!), and a certain uniqueness, even with a more-or-less generic 
term is good for one's ego (a major factor driving the OSS community, 
for example). ;)

And it would be difficult for larger projects (GForge, for example, is 
able to handle the organization of enterprise development) to stay 
consistent and, at the same time, easy to use.

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

This is something that the "newcomer" would have to do already.

All in all, your point is well taken and very much worthy of 
consideration. But since I've used all my arguments, I'll bow out of 
this discussion for the time being.

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

Rule of Open-Source Programming #37:

Duplicate effort is inevitable. Live with it.