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
- 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.
- 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.
- 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
···
On Friday, April 23, 2004, 2:25:54 AM, Dave wrote:
On Apr 22, 2004, at 10:22, Gavin Sinclair wrote: