[Rubygems-developers] 0.4.0 bugfix release

Gavin Sinclair gsinclair at soyabean.com.au
Mon May 31 11:18:55 EDT 2004


On Monday, May 31, 2004, 10:41:09 PM, Chad wrote:


> On 30/5/2004, at 9:13 PM, Gavin Sinclair wrote:

>>> FYI, Since we haven't seen a ton of activity recently on new features,
>>> I'm going to release 0.4.0 quietly this evening just to get the 
>>> newest,
>>> least-buggy code out for people to test/comment on.
>>>
>>> Chad
>>
>> Cool, thanks Chad.
>>
>> Last night, a friend and I brainstromed the look and feel of a 
>> Repository
>> object.  I'll collect my notes and post a summary when I get a chance.
>>

> Cool.

Well, no time like the present, but no time at the present,
unfortunately.

>> One thing, though.  I would like to support the mirroring of gems (i.e.
>> downloading them to a machine without installing them).  Those gems
>> would
>> then be available for local install, or for serving to other machines.
>>  Is
>> there support for this idea?
>>

> Definitely.  I want to use it to mirror the gems across multiple 
> sources for gem --remote availability.

>> # It's not something your everyday user would use, but it would
>> # bring advantages to power users, and it would facilitate the creation
>> # of mirrors, obviously.
>>
>> As a joke, I thought the holding place for such gems could be called
>> the
>> "cellar" - i.e. putting them away for later consumption.  Then I 
>> realised
>> I couldn't think of anything better.  What do you think?
>>

> Perhaps, "cache" starts to make more sense in this context to you? ;)
> Seriously, though, maybe we put these things into the 'cache' but in an
> uninstalled state.

Yeah, I think of "cache" as a low-level thing that maps names to
resources.  The Repository has several caches, and provides high-level
methods spanning all of them (e.g. list all gems without duplicates,
provide detailed report on gem availability, search descriptions, etc.)

Now, the thorny question is: at what level is this "state" (as in
"uninstalled state" above) maintained?

Is it a case of

  class Respository
    def initialize
      @installed_caches = [] # One cache for each gem directory.
      @cellared_caches = []  # One cache for each "cellar".
      @remote_caches = []    # One cache for each remote source.
    end
  end

or

  class Repository
    def initialize
      @cache = {}
        # e.g. cache["rake"] = [
        #   <installed gem in dir X>,
        #   <cellared gem in dir Y>,
        #   <remote gem on server Z1>,
        #   <remote gem on server Z2>
        # ]
    end

or something in between, or something else altogether?

Of course, as long as a good high-level interface is supported, the
implementation doesn't *really* matter.

Your statement about putting things into the cache in an uninstalled
state doesn't really gel with me because a cache is something that
exists only at runtime (it is persisted for efficiency), whereas a
cellared (downloaded but not installed) gem *is* a persisted object.
A cache contains only knowledge of a gem, it doesn't contain the gem
itself.  The repository uses its cache information to avail itself of
the resource (i.e. the gem), and hands it to whoever's asking
(installer, for instance).  The purpose of the cache is so the
repository knows whats available remotely without having to ask, thus
servicing list and info operations quickly.

Hmmmm... I'm well into brainstorming territory now, but that's got me
thinking: a *Gem* should be a first-class object, containing the spec
and all the file data (or at least the means to get the file data).
That way the Installer doesn't worry about unpacking, etc.; it just
grabs the data and writes to the correct files on disk.  A repository
is a machine that takes gem names and version requirements, and
returns Gem objects.  (Of course, the repo can return lists is that's
what you want).  The Repository exercises its best judgement on where
to get the gem from (if its already installed, get it from what we
presently call the cache; if it's in the cellar, get it from there; if
it's available remotely, grab it), and the output is the same: a Gem.

So much for "no time at the present"; I've gotta get to bed.  Some of
my thoughts are clarifying, and some are clouding...

Cheers,
Gavin




More information about the Rubygems-developers mailing list