[Rubygems-developers] What plans now?

[Curt Hibbs]

Gavin Sinclair wrote:
>
> > Curt Hibbs wrote:
>
> > I haven't looked at this in a few weeks, to maybe it has
> > changed, but the
> > main file that implements the command line interface mixes API
> > with command
> > interface. I remember wanting to separate these so that the command line
> > process requires/uses the same API file my GUI browser would use,
>
> No, nothing's changed :(  That's definitely something we need to
> address, but it may take a bit of sleeves-up dirty work.  I'm happy to
> do the dirty work, but I'd like some help from you on what the API
> should look like.

It seems to me that, logically, you have a repository object that lets you
do things with a repository, and a gem object that lets you do things with a
particular gem. Then I could do things like:

   remote = GemRepository.new("rubyforge.org")
   local  = GemRepository.new("local")

   remote = GemRepository.new("default")

   remote.each { |gem| remote_gems.add(gem) }
   local.each  { |gem| local_gems.add(gem) }

   a_gem = remote_gems[some_gem_name]

   # retrieving gem information
   a_gem.name
   a_gem.version
   a_gem.installed?

   # performing an actions
   a_gem.install
   a_gem.upgrade   # upgrade to latest version

> It's important to remember that various events can happen inside the
> API that different clients will handle differently.  For example,
> getting confirmation before installing a slew of dependencies.  Your
> client does something with dialog boxes; 'gem' uses STDOUT/STDIN.  We
> need to model that sort of interaction adequately.

Could yield blocks handle this?

   a_gem.install do |uninstalled_dependent_list|
      <ask-the-user>
      <return-true-or-false>
   end

Curt