------ art_2166_29961796.1128323393382 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Ok, So, I spent a chunk of time working through what I think would be a good solution to the directory structure/packaging stuff that has again plagued the ruby-talk mailing list. Here's what I think... Taking a complete step back, I see alot of extra stuff inside the ruby installation directory ... and here's what I think should be there ... The following is based on something like; /usr/ruby or /usr/local/ruby ( for linux/*nix users ) or c;\ruby or c:\program files\ruby ( for windows users ) ... from the ruby base installation directory ($RUBY_HOME) we should have the following: $RUBY_HOME/bin - which is where executables & scripts should live ( ruby, ri, irb, rdoc, rdoc_server, etc ) $RUBY_HOME/doc - which is where ALL documentation should exist ... $RUBY_HOME/doc/core - for documentation of the core objects in ruby $RUBY_HOME/doc/stdlib - for documentation of the objects outside of core that are included in the ruby distribution $RUBY_HOME/doc/... - each additional package should then get it's own documentation tree so that they are all easily delineated. $RUBY_HOME/etc - for things like irb.conf, gem.conf , gem.db ... whatever configuration files for default server packages ( like rdoc or gem or whatever else ) $RUBY_HOME/lib - all ruby source files & external libraries should go here. $RUBY_HOME/lib/ruby/ - all ruby source files $RUBY_HOME/lib/ruby/core/ - .rb files pertaining to core functionality $RUBY_HOME/lib/ruby/stdlib/ - .rb files that implement functionality for the stdlib $RUBY_HOME/lib/ruby/... - each additional package of .rb files should get a directory here ( same as the /doc/... name and purpose ) $RUBY_HOME/lib/ext/ - for all .dll or .so files that are included with Ruby or installed and required by ruby ... $RUBY_HOME/tests - for all unit tests $RUBY_HOME/tests/core $RUBY_HOME/tests/stdlib $RUBY_HOME/tests/... - breaking down the same way as $RUBY_HOME/lib/ruby or $RUBY_HOME/doc ... beyond this, I do like the idea of small self-contained files similar to java's .jar files ... I was trying to come up with something cute, but all I came up with is calling them .rib files ( matching the rake/rinda play on r-instead-of-l pronunciation ... rib as in "ruby lib" These .rib files would simply be a .tar.gz file mimicing the structure proposed above plus the addition of a metadata.yaml file. .rib files would simply enclose the entire structure of things for distributable functionality. The metadata.yaml file would include naming, versioning, dependancy, and other necessary information for making sure that things work (including rake files for running unit tests, or whatever else the package creator wanted it to do). As opposed to what we have for gems now, which frankly takes FOREVER to do simple installs of packages that are even only a few kilobytes... ( having to download the entire index EVERYTIME is a severe waste of bandwidth ) The rib server should be a distributed ruby ( drb ) server ( openssl ) that allows for a query/response way of finding out what's out there, instead of downloading an ever growing file and having all the work be done on the client side. The rib system should be platform sensitive ... meaning all calls would have platform specific filtering ... no-arch, linux-2.4, linux-2.6, osx, freebsd, etc ... lessening the amount of data that has to be transferred for any given call. The configuration of which rib or multiple rib servers should be called would be part of the configuration information stored in the $RUBY_HOME/etc directory. Using this as a standard would make things easier for all platforms as everybody would have hard paths to each and every place that they need to go ... and if a specific os or distro doesn't like wher things are , they can use where they want and just replace the directories I've proposed with symlinks ... ( so if they want /etc instead of $RUBY_HOME/etc ... just symlink it ) ... This solution would give a solid path for unit tests ( which is problematic under gems installed packages ) Also, I think this would be a good thing for getting all of the rdoc generated documentation into a single tree... and that would be a VERY good thing. ... it would still allow for multiple versions of libraries, as you could install /lib/ruby/my_package-1.3 & /lib/ruby/my_package-1.4 and simply symlink or stub for /lib/ruby/my_package to the current version. this would allow require 'my_package' for "latest version functionality" or require 'my_package-#.#' for specific version includes. I know it's re-inventing the wheel, but I think we've gotten so lost in trying to create a be-all solution that we're not solving the simplest portion of the problem ... and that's slowing ruby adoption. And that's what matters to me. So, I hope this note doesn't tick anybody off. I really just intend it as a fresh viewpoint. I've not done the necessary research to see how much of an impact this would have on the ruby distribution itself ... I think it would be easy ... This is just my brain dump ... and I hope it helps in some way ... if not, I'm sorry for the adding noise into the stream ... I believe this solution gives us maximum flexibility and allows the os distro/packaging systems to do what they need to do while not disturbing what we should be able to reliably expect. As always, your feedback is expected and appreciated. Thank you in advance for the amount of time you spent to read and hopefully understand my thoughts. j. -- "http://ruby-lang.org -- do you ruby?" Jeff Wood ------ art_2166_29961796.1128323393382--