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.