Asp Forum - Project vs. Package

Trans

4/19/2007 1:02:00 PM

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.

13 Answers

Robert Klemme

4/19/2007 1:30:00 PM

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

Avdi Grimm

4/19/2007 1:31:00 PM

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

Phillip Gawlowski

4/19/2007 1:39:00 PM

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.

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

--
Phillip "CynicalRyan" Gawlowski
http://cynicalryan....
http://clothred.rub...

Rule of Open-Source Programming #4:

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

Trans

4/19/2007 4:02:00 PM

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.

Phillip Gawlowski

4/19/2007 4:36:00 PM

Trans wrote:
>

>
> 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/...
[1] http://code.whythelucky...

--
Phillip "CynicalRyan" Gawlowski
http://cynicalryan....
http://clothred.rub...

Rules of Open-Source Programming:

22. Backward compatibility is your worst enemy.

23. Backward compatibility is your users' best friend.

Trans

4/19/2007 6:05:00 PM

On Apr 19, 12:36 pm, Phillip Gawlowski <cmdjackr...@googlemail.com>
wrote:
> Trans wrote:
>
> > 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

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.

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

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.

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

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

4/19/2007 6:45:00 PM

Trans wrote:
>
> On Apr 19, 12:36 pm, Phillip Gawlowski <cmdjackr...@googlemail.com>
> wrote:
>> Trans wrote:
>>
>>> 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
>
> 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 :)

>>> "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.
>
> 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....
http://clothred.rub...

Rule of Open-Source Programming #33:

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

Trans

4/19/2007 7:31:00 PM

On Apr 19, 2:45 pm, Phillip Gawlowski <cmdjackr...@googlemail.com>
wrote:
> Trans wrote:
>
> > On Apr 19, 12:36 pm, Phillip Gawlowski <cmdjackr...@googlemail.com>
> > wrote:
> >> Trans wrote:
>
> >>> 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
>
> > 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. ;)
...
> 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.)

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

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

T.

Phillip Gawlowski

4/19/2007 7:51:00 PM

Trans wrote:
>
> 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....
http://clothred.rub...

Rule of Open-Source Programming #1:

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

Sylvain Joyeux

4/19/2007 8:20:00 PM

> require 'traits', :project => 'codeforpeople', :package =>
> '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', :project => 'coolproject'
and
require 'heap', :project => '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.
--
Sylvain Joyeux

comp.lang.ruby

Project vs. Package

Trans

Robert Klemme

Avdi Grimm

Phillip Gawlowski

Trans

Phillip Gawlowski

Trans

Phillip Gawlowski

Trans

Phillip Gawlowski

Sylvain Joyeux

x Login to ForumsZone