From: Gavin Sinclair Date: 2004-04-23T07:58:37+09:00 Subject: Re: how to get ri/rdoc working for [user-installed libraries] On Friday, April 23, 2004, 2:25:54 AM, Dave wrote: > On Apr 22, 2004, at 10:22, Gavin Sinclair wrote: >>>> sensible system would require a change to ri. If you have 100 gems >>>> installed, and run 'ri --classes', I'm sure you don't want to see >>>> 1000 >>>> classes. >> >>> Why not? >> >> Because it's too much information to realistically browse. And it >> would be too slow. It takes about 2s for ri to show me all my classes >> now, and that's just core and (partial) stdlib. That's already close >> to too much. Doing any query takes at least as long. > Speeds a separate issue: ri and rdoc are implemented via a cache layer > (ri_cache), but I haven't implemented it yet. Once that's done, you'll > find that queries are a lot, lot faster. > You say it's too much information, but I dislike making policy decision > on behalf of users. If they ask for a full class listing, then I'll > give them one. If they want everything to do with X, then they can ask > for that. The opposite, where they have to know where stuff comes from, > seems to getr in the way. Agreed. Sorry, once again, I didn't make it clear that I wouldn't want to see existing functionality change. So 'ri -c' would still give you pages of stuff. That's especially unclear above. >> Would you think differently if gems were the one and only way people >> installed Ruby libs and apps? > I'd think differently if > 1. gems were built in to Ruby. The test for this is that there'd be no > more lib and ext directories, and the stuff needed to run gems was > built-in. If that were the case, gems would be the universal mechanism, > and Ruby would be distinguished as one of the few languages to > integrate package management. I don't think lib and ext directories would go away. Some of the stuff in libs could be more usefully be distributed as gems, but for the "core" of the stdlib, it's important to have it all in CVS. So future code might look like this: require 'singleton' require_gem 'rexml' Maybe in the future, require_gem will be phased out and require made to understand gems. > 2. the gem directory structure, versioning, and naming conventions were > universally adopted and understood Clearly, although you can always "require 'rubygems'" and use the interface methods to get a list of all gems, etc., etc. > 3. We understood better exactly how people use gems. >> >> "More transparent"? Possible, yes. We're discussing some >> transparency aspects on the list now. But here's a good litmus test >> question: do you think that ri should handle the fact that multiple >> versions of the same library are installed and have documentation? > No, I don't think this is a priority. ri is a developer tool, not an > end-user tool. Multiple versions of the libraries are (transparently) > significant to end users, but developers are probably interested > primarily in the current version's documentation. That's a policy decision on behalf of users. Not that I necessarily disagree. I suppose ri should be limited in scope as it is (obviously) limited in interface. Even so, to get the latest version's doc, you need to understand the gems library structure. > Versioning is a good example of somewhere where gems has a solution, > but I'm not sure of the problem. While it's good in theory to have > multiple verions of every library, I'm not sure that in practice its a > need I've ever had (and I'm a fairly active Ruby developer :) Me neither, but then I've never combined a *lot* of libraries into a single project. I've certainly seen it mentioned a few times on the list. Versioning is something that will take a long time to take hold, because you need to write code like "require_gem 'log4r', '> 1.0.5'". Maybe it never will, but the structure of each package installed in its own area, and including version number, is sound, I believe. And the beauty of it is that it's "backwards compatible", in that require_gem will by default select the latest available version. And 'require' will work with gems as well (via a stub in site_ruby/1.x that loads the gem). > Instead, I have versions ties to the version of the interpreter: on by > current box, I have four interpreter trees, each with their > then-current versions of libraries. If I run a different version of the > interpreter, I get that interpreter's versions of the libraries. That's a lot of manual effort, by the sound of it. > Now I know that I'm probably just being curmudgeonly about this, but > I'm one of those people who need to experience the need before > expending a bunch of energy writing the code. In this case, I'm not > sure about the versioning scheme in general, and then who the > interaction between user categories, versions, and documentation takes > place. I'd rather not code into that vacuum. Let's get some practice > experience first, and then take a position. Fair enough. It will take some getting used to. Cheers, Gavin P.S. We still don't know what approach to take to get ri data installed when you install a gem :)