Re: Project vs. Package

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.

.

Relevant Pages

  • Re: Project vs. Package
    ... libs in my libs", irregardless of gems. ... distribution is tied into the GEM_SPEC, for example, but you can ... "packages" are what we distribute. ... packages at RubyForge. ...
    (comp.lang.ruby)
  • Re: Fedora Extras is extra
    ... BTW Some Red Hat packages used to have similar things ... > external contraints allow you to bend to work inside what fedora ... > but not their own infrastructure for distribution. ... Fedora Extras will have the same policy. ...
    (Fedora)
  • Re: Secrecy and user trust
    ... Were packages signed by the replacement key distributed? ... trusted "new" public key, it can be used to check the signing on any ... The current distribution has the ability to do this, ... I can't say if any updates past the install ...
    (Fedora)
  • embedded linux distributions, a few thoughts
    ... open source distribution that I can customize and recompile from ... packages which are tested together, ... care for .debs to be involved either, if not as packages for the host ... out a quick x86 system" so that it would be easy to start trying them out. ...
    (comp.os.linux.embedded)
  • Re: Debian has turned unusable.
    ... post before blaming Debian for your problems. ... and the packaging method was unique among all linux deriatives ... > I then tried to figure out how to update those packages i need in ... distribution, not just one package. ...
    (Debian-User)