Project vs. Package

[Trans]

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', roject => 'codeforpeople', ackage =>
'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.

 

[Robert Klemme]

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', roject => 'codeforpeople', ackage =>
'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

 

[Avdi Grimm]

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?

 

[Phillip Gawlowski]

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 roject, :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.


P.S.:
For GForge's rationale behind the distinction project <> package, you'd
have to contact the Sourceforge inventors.

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

Rule of Open-Source Programming #4:

If you don't work on your project, chances are that no one will.

 

[Trans]

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 roject, :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.

 

[Phillip Gawlowski]

You speak of well established community standards, well what are they?

For developers:
place libraries in /lib
place executables in /bin
place documentation in /doc

And then there's ESR's Software Release Practice HOWTO[0], too, as a
super-set of rules an OSS community especially, but development in
general, too, can and mostly do follow.

These are important for developers.

"Use RubyGems" is not an answer to the questions raised. And this is

It is, for the end-user of software. The most people don't want to mess
with configuration, downloads, and three steps until their software is
installed, and RubyGems provides a good interface that does make it easy
to handle the installation of software.

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.

Which is not a problem of Project vs. Package, but a problem of lack of
research vs. existing facts, and ignorance concerning existing
structures. That is not just a problem of community standards, but
"industry standards", too (hard coded program paths in Windows software
installations, for example), or placement of libraries in different
paths (a common problem with Linux distributions).

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

Yes, and at the same time no. Yes, how I structure the files for
distribution is tied into the GEM_SPEC, for example, but you can
circumvent that by using the GEM_SPEC, and my rake task doesn't care how
deeply nested my development setup is, when gathering the files to build
the gem distribution. If these tools would work blindly, I'd be
redistributing a lot of cruft with my gems, as the .svn and nbproject
directories would be distributed, too. And they aren't. At the same
time, I could tell my gems to load the directory foo/ instead of lib/,
if I were so inclined (which I'm not).

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

Yes, packages do. But not projects. I probably wasn't clear enough in
divorcing the two.

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.

No, a project is the organizational structure of a "software firm"
(example: seattle.rb), or a development "department" (Rails handling of
the different packages, for example). These two philosophies just happen
to use the same infrastructure.

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.

Well, I'd love to drop my libs and scripts into the ruby directory, too,
as it would be convenient. Instead I either use the created gem, or
have a directory to call scripts from (placed into the PATH of my OS,
for ease of use).

Otherwise, I don't see any issue with the way RubyForge is organized (or
GForge in general), but rather with the perception of these. This could
arise from the fact, that most developers choose the "one project - one
package" approach, but that isn't tied into RubyForge, as _why follows a
similar approach (at least to a mundane like me at his repository[1]

I have the feeling, that you could be reading too much into projects and
packages at RubyForge.

References:
[0] http://en.tldp.org/HOWTO/Software-Release-Practice-HOWTO/index.html
[1] http://code.whytheluckystiff.net/

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

Rules of Open-Source Programming:

22. Backward compatibility is your worst enemy.

23. Backward compatibility is your users' best friend.

 

[Trans]

For developers:
place libraries in /lib
place executables in /bin
place documentation in /doc

Of course, those are known standards, the issue with require is the
layout of the things in lib/.

And then there's ESR's Software Release Practice HOWTO[0], too, as a
super-set of rules an OSS community especially, but development in
general, too, can and mostly do follow.

These are important for developers.

Good resource, thanks.

It is, for the end-user of software. The most people don't want to mess
with configuration, downloads, and three steps until their software is
installed, and RubyGems provides a good interface that does make it easy
to handle the installation of software.

For the end-developer there's still the question, "how do I use your
libs in my libs", irregardless of gems.

Which is not a problem of Project vs. Package, but a problem of lack of
research vs. existing facts, and ignorance concerning existing
structures. That is not just a problem of community standards, but
"industry standards", too (hard coded program paths in Windows software
installations, for example), or placement of libraries in different
paths (a common problem with Linux distributions).


Yes, and at the same time no. Yes, how I structure the files for
distribution is tied into the GEM_SPEC, for example, but you can
circumvent that by using the GEM_SPEC, and my rake task doesn't care how
deeply nested my development setup is, when gathering the files to build
the gem distribution. If these tools would work blindly, I'd be
redistributing a lot of cruft with my gems, as the .svn and nbproject
directories would be distributed, too. And they aren't. At the same
time, I could tell my gems to load the directory foo/ instead of lib/,
if I were so inclined (which I'm not).

And for good reason. It would make alternate means of packaging a
nightmare --basically locking oneself into using gems and gems only.

Yes, packages do. But not projects. I probably wasn't clear enough in
divorcing the two.

Okay. Then I see more of what you're getting at.

No, a project is the organizational structure of a "software firm"
(example: seattle.rb), or a development "department" (Rails handling of
the different packages, for example). These two philosophies just happen
to use the same infrastructure.

Otherwise, I don't see any issue with the way RubyForge is organized (or
GForge in general), but rather with the perception of these. This could
arise from the fact, that most developers choose the "one project - one
package" approach, but that isn't tied into RubyForge, as _why follows a
similar approach (at least to a mundane like me at his repository[1]

I have the feeling, that you could be reading too much into projects and
packages at RubyForge.

So I had the right perception the first time? You're saying forget
"project" (in the Rubyforge sense of the word) as having anything to
do with a software distribution. It's just a means of development
organization and nothing more. Project's probably a poor term then.
Though Rubyforge uses it, a better term would be "Repository".

Rules of Open-Source Programming:

22. Backward compatibility is your worst enemy.

23. Backward compatibility is your users' best friend.

That's for sure!

Thanks,
T.

 

[Phillip Gawlowski]

Of course, those are known standards, the issue with require is the
layout of the things in lib/.

Where, for example, the PickAxe has the handy tip of placing a single
file in there, which contains your "custom" requires, for example.

i.e.:
mylibrary.rb (which gets called in your script) could contain:
require 'foo/part1'
require 'bar/api'
require 'baz/42/obscurestuff.rb'

Convention over configuration. That doesn't work just for Rails.

And then there's ESR's Software Release Practice HOWTO[0], too, as a
super-set of rules an OSS community especially, but development in
general, too, can and mostly do follow.

These are important for developers.

Good resource, thanks.

You are welcome

For the end-developer there's still the question, "how do I use your
libs in my libs", irregardless of gems.

But this is more an effect of development of the library one wants to
use. This can be circumvented a bit by using the library as a dependency
in a gem, or by redistributing it. Place it in contrib/ and require
'contrib/other_library', for example.

But that is more a problem of software development and documentation of
APIs (or the lack there of!), than distribution of code.

So I had the right perception the first time? You're saying forget
"project" (in the Rubyforge sense of the word) as having anything to
do with a software distribution. It's just a means of development
organization and nothing more. Project's probably a poor term then.
Though Rubyforge uses it, a better term would be "Repository".

Well, I guess "Team" would be more appropriate, but "Repository" covers
it, I think. And yes, RubyForge's Projects are there for organizational
and planning purposes, but aren't related to software distribution.

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

Rule of Open-Source Programming #33:

Don't waste time on writing test cases and test scripts - your users are
your best testers.

 

[Trans]

Where, for example, the PickAxe has the handy tip of placing a single
file in there, which contains your "custom" requires, for example.

i.e.:
mylibrary.rb (which gets called in your script) could contain:
require 'foo/part1'
require 'bar/api'
require 'baz/42/obscurestuff.rb'

Convention over configuration. That doesn't work just for Rails. ...
But this is more an effect of development of the library one wants to
use. This can be circumvented a bit by using the library as a dependency
in a gem, or by redistributing it. Place it in contrib/ and require
'contrib/other_library', for example.

But that is more a problem of software development and documentation of
APIs (or the lack there of!), than distribution of code.

Actually, for me it's much more difficult because I mostly write libs
and not apps. It's not as simple as a single .rb file to require. I
have a large collection of them, each needs to be requirable. This
problem arises elsewhere too, for instance, using CodeForPeople's
traits lib. It's isn't

require 'codeforpeople/traits'

it's

require 'traits'

Effectively CodeForPeople has taken a monopoly on the term 'traits'.
That might not seem a big deal (and note I'm not worried about the
particular case, it's just an example), but multiple that by 70 and
you'd be sitting in my shoes (yes I have 70+ small libs to
distribute). Multiple that by another factor of 100 or more as Ruby
becomes an increasingly popular language, and we really have the
potential for name clash issues.

(To give you an example, should I take ownership of the gem names
'heap', 'pool' and 'version', each of which are useful libs which I
have to distribute.)

Well, I guess "Team" would be more appropriate, but "Repository" covers
it, I think. And yes, RubyForge's Projects are there for organizational
and planning purposes, but aren't related to software distribution.

Fair enough. But I guess I'm really asking, if it should. Maybe we'd
be better off if it did?

T.

 

[Phillip Gawlowski]

Actually, for me it's much more difficult because I mostly write libs
and not apps. It's not as simple as a single .rb file to require. I
have a large collection of them, each needs to be requirable. This
problem arises elsewhere too, for instance, using CodeForPeople's
traits lib. It's isn't

require 'codeforpeople/traits'

it's

require 'traits'

Effectively CodeForPeople has taken a monopoly on the term 'traits'.
That might not seem a big deal (and note I'm not worried about the
particular case, it's just an example), but multiple that by 70 and
you'd be sitting in my shoes (yes I have 70+ small libs to
distribute). Multiple that by another factor of 100 or more as Ruby
becomes an increasingly popular language, and we really have the
potential for name clash issues.

I guess I should start using a prefix, then.

On the other hand, facets handles that particular problem (lots of
little things), as does Ruby (stdlib!).

Without deeper knowledge of your libs, I've come up with this example:

RubyForge Project: TransLibs

Packages:
tl_network (required as "network/lib1", "network/lib2" etc..
tl_administration (required as "administration/lib1",
"administration/lib2§ etc.)

And to prevent it completely, you could add a prefix. Or you could just
leverage rubygems, so that require "net/translib1" works, for example.

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.

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.

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

Rule of Open-Source Programming #1:

Don't whine unless you are going to implement it yourself.

 

[Sylvain Joyeux]

require 'traits', roject => 'codeforpeople', ackage =>

'traits', :version => '>= 0.10'

I think this is over-engineering for a very marginal problem.

If you have a 'heap' library, you usually don't want it to be top-level,
because heaps are a general thing and it is very likely that you heap is
not compatible with another's, so
require 'heap', roject => 'coolproject'
and
require 'heap', roject => 'anothercoolproject'
are NOT equivalent. For this kind of library, it is IMO not that horrible
to have to type
require 'coolproject/heap'

If you're defining a big library, it can be put in the 'toplevel'
namespace, because the first one that will use a name will own it.

This works for a very long time in C (with both library names and
includes). Of course, there are problems but I really think what you're
trying to do is overkill for a very limited problem.

I don't know what's your problem with more's libraries being in more. I
personally don't see one.

 

[Trans]

I guess I should start using a prefix, then.

On the other hand, facets handles that particular problem (lots of
little things), as does Ruby (stdlib!).

Without deeper knowledge of your libs, I've come up with this example:

RubyForge Project: TransLibs

Packages:
tl_network (required as "network/lib1", "network/lib2" etc..
tl_administration (required as "administration/lib1",
"administration/lib2=A7 etc.)

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.

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?

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

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, IM=

O=2E

Oh, I actually meant a standard means of require. For instance, we
always should use:

require 'myproject/mypackage/mylib'

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.

T=2E

 

[Phillip Gawlowski]

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.

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.

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.

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.

 

[Robert Klemme]

Actually, for me it's much more difficult because I mostly write libs
and not apps. It's not as simple as a single .rb file to require. I
have a large collection of them, each needs to be requirable. This
problem arises elsewhere too, for instance, using CodeForPeople's
traits lib. It's isn't

require 'codeforpeople/traits'

it's

require 'traits'

Effectively CodeForPeople has taken a monopoly on the term 'traits'.
That might not seem a big deal (and note I'm not worried about the
particular case, it's just an example), but multiple that by 70 and
you'd be sitting in my shoes (yes I have 70+ small libs to
distribute). Multiple that by another factor of 100 or more as Ruby
becomes an increasingly popular language, and we really have the
potential for name clash issues.

Whatever you do (call it prefixes, namespaces or whatnot) there will
always be a point of potential collision. Java has taken the route to
use domain names as package discriminators which is probably a good
idea. But you cannot enforce that and it seems that in Java land people
tend to omit the leading "com" which surely increases the potential for
collisions; but this does not seem to be an issue in practice. There is
simply no completely safe solution other than having a global
institution that hands out package prefixes / directory names.

Kind regards

robert