On Apr 19, 2:45 pm, Phillip Gawlowski <cmdjackr... / googlemail.com>
wrote:
> 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. ;)
...
> 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.