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 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. > "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. > not about whether there is a "problem" or not. Whatever problem there > are, clearly we work around to get things done, that doesn't make it > less of a issue to be considered and discussed. There are very real > issues that can, and do, arise: Rubyforge projects having gem packages > of the same name; packages, gem or otherwise, adding files to ruby > lookup path willy-nilly which can upset gem requires and clobbers > files for manual installs; module namespaces clashes, etc. 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). > I wonder how many ruby projects/packages you distribute. The > development of them is completely tied up in their distribution. First > of all, the layout of a project/package one must use in development is > pretty much a given, since out tools recognize it automatically in > putting together packages (eg. setup.rb, gem build). There are tricks 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). > 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. > thought of a project as the development state of a package. The two > were basically the same in my mind, just for different modes of usage. > Only later in thinking about Rubyforge, did I start to see them as > distinct and that maybe I should start to reflect that in my > development model as well. 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. > Personally, I'd like to drop all my libs right in the top most lib > directory. That's very convenient. But I know that's not going to fly > in sharing them. So I need to accept some constraints and standards > for their organization to play nice. In trying to reasonably do so, I > have found the fore mentioned issues --which I have characterized > largely as a consequence of project vs. package. But irregardless of > the larger depiction the same fundamental issues remain. Well, I'd love to drop my libs and scripts into the ruby directory, too, as it would be convenient. Instead I either use the created gem, or have a directory to call scripts from (placed into the PATH of my OS, for ease of use). 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. References: [0] http://en.tldp.org/HOWTO/Software-Release-Practice-HOWTO/index.html [1] http://code.whytheluckystiff.net/ -- Phillip "CynicalRyan" Gawlowski http://cynicalryan.110mb.com/ http://clothred.rubyforge.org Rules of Open-Source Programming: 22. Backward compatibility is your worst enemy. 23. Backward compatibility is your users' best friend.