From: Hugh Sasse Date: 2005-10-03T21:32:48+09:00 Subject: Re: packages, gems, libraries ... and ruby itself. On Mon, 3 Oct 2005, Jeff Wood wrote: > 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. [...] > > 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 ) To be fair, there is effort to reduce this time to something more reasonable, and a number of schemes have been looked at (better usage of the protocols, breaking up the zipped archive to smaller chunks,...). As to when the problem will disappear, I cannot say. There is mention of this on the TODO list. > > The rib server should be a distributed ruby ( drb ) server ( openssl ) that That (openssl) would exclude users of ruby in places where encryption is legally difficult. I mention this solely on the basis that we seem to be aiming for the widest uptake possible... [...] > ... 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 ) ... As mentioned recently, symlinks are not cross-platform, alas. > > This solution would give a solid path for unit tests ( which is problematic > under gems installed packages ) Details on the problems encountered may facilitate improvemnts in the existing system, while development continues on your proposal. > > 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. The documentation structure is under consideration as part of the proposed integration of rubygems. > > ... 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. Austin has already mentioned problems with a suffix based scheme a couple of times recently. > > 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. I know there seems to be more heat than light at the moment, but the rubygems TODO list does cover a lot of these points and more. http://rubygarden.org/ruby?action=browse&diff=1&id=RubyGemsToDoList > > 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 ... I suspect that it would be difficult, given the effect of change on existing software. The scheme looks simple and straightforward, but then I have a unix background, and people from elsewhere might not see it as so clear. Also, I think it breaks backward compatibility, because you plan to move things around significantly. > > 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. Well, I don't want to stamp on new ideas before they show promise. I remain to be convinced about this one... > > 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. > Hugh