>> There's actually an ugly way to do it. E.g.:
>>
>> Gem::SourceInfoCache.new.cache_data.values.map{|s|
>> s.source_index.map{|g| g.first}}.flatten
>
> It would be best if we could work with the data on-hand. I don't
> know how to determine when we're too stale though.
It could be left up to users ? Some options:
a) a flag on install / list
b) update local cache only on 'outdated' or 'update'
c) go the apt route and add a command specifically to refresh the
local cache.
In any case, even if the default 'gem' behaviour was to *always*
update before any operation, and there was no CLI command to do it,
providing a programmatic way to search the local cache would be
useful for tool developers (by which, of course, I mean specifically
me :).
The thing I'm building, which again I stress is mostly a RubyCocoa
learning tool, is a two-tab window with 'local' and 'remote'. I aim
to be able to 'remove' and 'install' respectively. I've added a
'live' search to each tab which also works fine right now. I'm
planning to do such arbitrary operations as 'find all other gems by
this author', and 'fire up a gem_server and start a browser on the
help for this gem'
I can successfully populate both local and remote, but right now I've
opted for a manual 'retrieve' button on the remote tab since the app
hung for a fair-old-while when loading the remote gems. If I could
load the remote gems piecemeal and refresh the GUI as new gems are
discovered, that'd be perfect. Perfect being somewhat unattainable
I'd love to just populate (quickly) from local cache, check for
outdated version when installing, and add a user operation to update
the cache.
Any thoughts on any of this welcomed as a somewhat academic discussion.
A.
--
http://www.alancfrancis.com/
http://www.cardboardsoftware.com/
http://www.scotlandonrails.com/
_______________________________________________
Rubygems-developers mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/rubygems-developers
