On 4/19/07, Trans <transfire / gmail.com> wrote:
> It took me some time to rationalize the situation. There's a bit of a
> contention in the Ruby about how apps/libs are distributed. The
> contention lies between the concept of "project" and "package". For a
> long time, I did not distinguish the two --and I think most people do
> not, largely b/c RubyGems has no notion of project --everything is
> just a package. But Rubyforge does distinguish --for each project
> there can be many packages. This discrepancy, between these two
> monoliths of Rubydom, is unfortunate. I have never seen any address of
> this, and I suspect it's b/c it simply evolved, rather then being
> rationalized from the start and set in place.

Is this really a problem in practice?  I can't think of any instance
where this caused trouble for me.

Sure, there's a conceptual elegance to a system like Java has, where
everything is neatly namespaced by provider, project, subproject, etc;
e.g. "import org.apache.commons.jxpath.*" means "give me the 'jxpath'
package from the 'commons' project provided by the Apache Foundation".
 But in actual practice Ruby's ad-hoc system of package naming doesn't
seem to be getting in anyone's way [yet].  Is it?

--
Avdi