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.