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.

If you look at the projects on Rubyforge, you'll notice that the most
of them essentially equate project to package, ie. each project has
but one package of the same name. Indeed, even Rails took this
approach -- ActiveRecord, ActionPack, ActionMailer, etc. are all
separate projects on Rubyforge. On the other hand, projects like
Seattle.rb and CodeForPeople have embraced the has_many packages idea.
For them, the idea of a "project" is aligned more-or-less with the
concept of "provider". I wonder what the original intention of GForge
was in having multiple packages per project.

In further considering this, I also wondered how it effects our
require statements. Usually we see statements like:

  require 'myproject/mylib'

where 'myproject' could just as well be 'mypackage', since there's no
distinction made. But when we take the consideration into account,
then what? Do we use myproject or mypackage or both? It would seem the
most formal approach would be:

  require 'myproject/mypackage/mylib'

But who wants to write all that for every require statement? ;-)  And
what if a package moves to a different project --say Seattle.rb turned
over a package to CodeForPeople. Is it a different require now just b/
c of that? So I wondered, what could require look like if we isolated
these aspects, for example:

  require 'traits', :project => 'codeforpeople', :package =>
'traits', :version => '>= 0.10'

And then, perhaps we could omit any or all of the three options and it
could find the most recent matching lib for us?

  require 'traits'

would do the same as above, if no other project/package has a
traits.rb lib. Clever, but probably too ambiguous.


I wonder what others take on this. Has anyone considered this
distinction between project and package before? How should this
distinction be used? How should it effect the organization of our apps
and libs. It would be nice to have some sort of community consensus on
this and see it taken up by the important projects that help define
the standards on these matters.

T.