[Rubygems-developers] Thoughts on integrating ri and rubygems

Chad Fowler chad at chadfowler.com
Sat Mar 27 08:37:29 EST 2004


On Mar 27, 2004, at 8:05 AM, Gavin Sinclair wrote:

> Hi guys,
>
> I don't know if you've had previous discussions on this topic.  Here
> are my thoughts.
>
> If a person has 100 gems installed, and all of them are in a global
> 'ri' data area, then ri is likely to be very slow for several of its
> operations.  It's also against the rubygems policy to install things
> in a shared area except in special cases.
>

Just to clarify, this speed issue wouldn't be specific to RubyGems, 
would it?  I mean that if someone had installed the same 100 libraries 
via the traditional means, it would still be slow.  Or, am I missing 
something?


> Given a gem 'copland', then, we might expect rubygems to install its
> ri data in
>
>   /usr/local/lib/ruby/gems/1.8/doc/copland/ri
>
> for example.
>
> The trick, then, is for ri to know where to find these bits of ri
> data.  ri should provide the following features:
>
>   ri --gem copland           # Show all classes in that gem
>
>   ri --gem copland Builder
>   ri --gem copland build
>   etc.                       # Run normal ri queries, but only on
>                              # that gem
>
> That requires a pretty straightforward modification to ri.
>

I guess this is a question for Dave as much as it is a question for 
RubyGems' developers.  If I were Dave, I would want to see RubyGems 
solidify quite a bit before polluting ri with additional options and 
behavior.  Even if it did solidify, I would probably be looking for a 
way to make things more transparent.  Unfortunately, since I'm not 
Dave, I don't have any brilliant ideas of how to make it transparent 
right now ;)


> What remains to be seen, though, is whether ri and gems can work
> together in an unfettered way, with ri making use of *all* of the
> available ri data at once.
>

I think that's true.  I guess I need to spend a little more time 
playing with ri to develop an opinion.

Chad



More information about the Rubygems-developers mailing list