On Apr 19, 9:38 am, Phillip Gawlowski <cmdjackr... / googlemail.com>
wrote:
> Trans wrote:
> > 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 have noticed, that this distinction doesn't, actually, exist. The
> development and distribution of applications and libraries is handled by
> community standards, that are published in, for example, the PickAxe.
> RubyGems make a distinction between package and project even more
> superfluous.
>
> I have yet to type require 'anothersproject/anotherslib/hoe' when
> needing hoe. Don't mix the development environment with the actual
> distribution (there are a few directories and files in my project's file
> hierarchy, which don't get distributed) of a more-or-less finished product.
>
> In essence, the terms "project" or "package" have nothing to do with
> Ruby or how it handles third party add-ons. Those terms are used to make
>   it easier to handle the *development* and necessary *collaboration*,
> but don't influence the way applications or libraries are distributed,
> let alone used.
>
> This is handled by the community standards that are well established,
> and reinforced by publication (i.e. PickAxe, and I'm sure The Ruby Way
> has something similar).
>
> And honestly, meta-data like :project, :maintainer and what not aren't
> necessary to handle the management of gems. If you want to use a gem,
> you need the name of the gem for require, and, maybe, the version of a
> package. The only area where I can see that it would be a problem is
> when two different projects pick the same name for different libraries /
> apps, and the chances of this happening are low, I'd say.
>
> All in all, I think you see a problem where there is none. If complete
> newbies (like I was) flood the mailing list with "What's a package?
> what's a project?", instead of "How do I require this gem?", then there
> is a problem in the distinction, but all resources make it pretty clear
> that the Gem is the method of choice to install 3rd party tools.

You speak of well established community standards, well what are they?
"Use RubyGems" is not an answer to the questions raised. And this is
not about whether there is a "problem" or not. Whatever problem there
are, clearly we work around to get things done, that doesn't make it
less of a issue to be considered and discussed. There are very real
issues that can, and do, arise: Rubyforge projects having gem packages
of the same name; packages, gem or otherwise, adding files to ruby
lookup path willy-nilly which can upset gem requires and clobbers
files for manual installs; module namespaces clashes, etc.

I wonder how many ruby projects/packages you distribute. The
development of them is completely tied up in their distribution. First
of all, the layout of a project/package one must use in development is
pretty much a given, since out tools recognize it automatically in
putting together packages (eg. setup.rb, gem build). There are tricks
to divorce the two, but the usually its not worth the trouble.
Moreover, "packages" are what we distribute. So they have everything
to do with how Ruby handle's third party add-ons. For a long time I
thought of a project as the development state of a package. The two
were basically the same in my mind, just for different modes of usage.
Only later in thinking about Rubyforge, did I start to see them as
distinct and that maybe I should start to reflect that in my
development model as well.

Personally, I'd like to drop all my libs right in the top most lib
directory. That's very convenient. But I know that's not going to fly
in sharing them. So I need to accept some constraints and standards
for their organization to play nice. In trying to reasonably do so, I
have found the fore mentioned issues  --which I have characterized
largely as a consequence of project vs. package. But irregardless of
the larger depiction the same fundamental issues remain.

T.