Project vs. Package

Discussion in 'Ruby' started by Trans, Apr 19, 2007.

  1. Trans

    Trans Guest

    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.
    Trans, Apr 19, 2007
    #1
    1. Advertising

  2. 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
    Robert Klemme, Apr 19, 2007
    #2
    1. Advertising

  3. Trans

    Avdi Grimm Guest

    On 4/19/07, 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.


    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
    Avdi Grimm, Apr 19, 2007
    #3
  4. 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.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.
    Phillip Gawlowski, Apr 19, 2007
    #4
  5. Trans

    Trans Guest

    On Apr 19, 9:38 am, Phillip Gawlowski <>
    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.
    Trans, Apr 19, 2007
    #5
  6. 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/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.
    Phillip Gawlowski, Apr 19, 2007
    #6
  7. Trans

    Trans Guest

    On Apr 19, 12:36 pm, Phillip Gawlowski <>
    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.
    Trans, Apr 19, 2007
    #7
  8. Trans wrote:
    >
    > On Apr 19, 12:36 pm, Phillip Gawlowski <>
    > 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.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.
    Phillip Gawlowski, Apr 19, 2007
    #8
  9. Trans

    Trans Guest

    On Apr 19, 2:45 pm, Phillip Gawlowski <>
    wrote:
    > Trans wrote:
    >
    > > On Apr 19, 12:36 pm, Phillip Gawlowski <>
    > > 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.
    Trans, Apr 19, 2007
    #9
  10. 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.110mb.com/
    http://clothred.rubyforge.org

    Rule of Open-Source Programming #1:

    Don't whine unless you are going to implement it yourself.
    Phillip Gawlowski, Apr 19, 2007
    #10
  11. > 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
    Sylvain Joyeux, Apr 19, 2007
    #11
  12. Trans

    Trans Guest

    On Apr 19, 3:51 pm, Phillip Gawlowski <>
    wrote:
    > 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=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 ;-)

    > > 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, 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
    Trans, Apr 19, 2007
    #12
  13. Trans wrote:
    > 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.

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


    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.

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


    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.

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

    >
    > 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.
    Phillip Gawlowski, Apr 19, 2007
    #13
  14. On 19.04.2007 21:31, 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.


    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
    Robert Klemme, Apr 20, 2007
    #14
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Parvinder
    Replies:
    6
    Views:
    732
    Thomas G. Marshall
    Feb 27, 2005
  2. Dave
    Replies:
    2
    Views:
    455
  3. George P
    Replies:
    3
    Views:
    670
    Alex Martelli
    Sep 11, 2004
  4. David Pratt
    Replies:
    4
    Views:
    324
    David Pratt
    May 13, 2006
  5. Replies:
    1
    Views:
    15,051
    drobert_bfm
    Nov 27, 2007
Loading...

Share This Page