Re: Project vs. Package



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


.

Relevant Pages

  • Re: Project vs. Package
    ... issues that can, and do, arise: Rubyforge projects having gem packages ... 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. ... Only later in thinking about Rubyforge, did I start to see them as ...
    (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)
  • 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)
  • Re: *ALERT* UPDATED BID 3163 (URGENCY 6.58): Sendmail Debugger Arbitrary Code Execution Vulnerabilit
    ... Sendmail Debugger Arbitrary Code Execution Vulnerability ... The 7.x distribution update directories contain update packages for the ...
    (Bugtraq)