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