[Rubygems-developers] What plans now?

Gavin Sinclair gsinclair at soyabean.com.au
Sun May 16 19:13:16 EDT 2004

> 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")

Yeah, not bad, though I'd rather see one giant repository (which can be
sliced, diced, and searched in various ways).

The benefit of a giant repository integrating local and remote gems is
that you can do easily things that are useful for the user; e.g. searching
for uninstalled gems matching X, without returning duplicate results from
different sources.

>    remote.each { |gem| remote_gems.add(gem) }
>    local.each  { |gem| local_gems.add(gem) }
>    a_gem = remote_gems[some_gem_name]

What are local_gems and remote_gems here?

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

I like it.

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

I like it.

>> 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

Yes, but I'm pretty sure there are cases where more than one 'signal' can
be generated by the method.  In which case we could get by with something
like this:

  a.gem.install do |signal, arg|
    case signal
    when :uninstalled_dependencies
      <ask the user>(arg)
      <return true or false>
    when :something_else

That has a certain appeal, but I've never seen Ruby code like it before. 
Something to think about.  I'll see if I can find a case where more than
one "handler" is necessary.

As for Chad's continuation-based idea, down that road lies madness! 
(Sorry, just had to say that.)  I think that would get rather complicated,
rather quickly.  And to do it properly, we'd end up reimplementing Borges


More information about the Rubygems-developers mailing list