On 19.04.2007 15:01, Trans 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.
> 
> 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'

Frankly, I'd rather type the former than this.

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

Yes, too ambiguous IMHO.

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

I think the terms are just orthogonal.  A project is something 
completely different from a package.  A project can have any number of 
packages and any number of projects can provide code for a single packaged.

Kind regards

	robert