[Zope-dev] Re: [ZODB-Dev] More CVS shifting

[Ken Manheimer]

This is a followup on a message i originally posted to zope-announce and
zodb-dev.  I'm transferring the discussion to zope-dev and zodb-dev, since
zope-announce is not for discussion, and i expect there are many
repository users who subscribe to one of zodb-dev or zope-dev but not
both.

On Thu, 2 Aug 2001, Jim Fulton wrote:

> > new scheme, it will mean having to once again do new checkouts - old
> > checkouts will not update.
> 
> Old checkouts will certainly update, but they won't reflect module
> changes, because modules *only* affect checkouts.

Yes - that's what i meant to say.

> >  - Modules enable a bit more recipe reuse.  For instance, if you
> >    wanted two different versions of Zope, one with CMF included and
> >    one without, you could reuse a core Zope module in a ZopePlusCMF
> >    module.  We will be able to compensate, perhaps better, with
> >    distribution front-ends.
> 
> Please elaborate how symlinks hinder this.  If we need distribution 
> front ends, then we might as well provide distribution front ends to 
> overcome the module problem.

Someone else asked this question in a private conversation, and i
came to realize this is an important issue, which i addressed in some
detail:

First off, i may have been unclear.  Symlinks should enable the
fundamental goal where you're able to project various elements from
the repository into other directories.  I know i've used them for this
before, just want to verify my recollection and check the edges, as i
describe above.

There's a limit to how far we can go with this, relative to modules,
without some elaboration.  It has to do with reusing directories that are
populated using symlinks.

Using symlinks, the directories getting shared elements actually contain
the links to the elements, so in the simplest approach they must have the
same populations in any recipe where they're used.  (I think we can
address that with another layer of indirection using relative symlinks -
see below.)

The module scheme directly offers some more freedom, here - the weaving
is a virtual thing, so that directories populated using modules can be
populated differently in different recipes.

For example:

  In the current setup, the Zope-specific parts of the Zope module are
  woven in from Releases/Zope - i'd call this the skeleton.  Various
  products and packages are projected into that skeleton with further
  module elaboration.  It could be that we'd have a ZopePlusCMF module
  that wove in the Zope module and then additionally projected the CMF
  products.  With the symlink scheme we would have to have a separate
  skeleton.

In describing the situation i came to realize that we can use relative
symlinks to achieve this kind of reuse, with a bit of elaboration:

  The idea is to have relative-link stubs in the skeletons, which
  indirect to directories that vary across recipes.

  For example, the Zope skeleton would have a link for
  lib/python/Products that points to ../../Products.

  Then, a few Zope variants would look like so::

    Zope/
         ==> link to Zope skeleton
         Products/
           ... various products specific to the plain Zope packaging
    ZopeWithCMF/
         ==> link to Zope skeleton
         Products/
           ... various products specific to the Zope + CMF packaging

  In both cases, the Products link in the Zope skeleton would indirect
  to the recipe-specific Products dir.  Viola.          

By "distribution front-end" i was (lazily and hazily) referring to some
kind of installation mechanism by which people would select the overlays
they want to add to their base-line installation - eg, they'd checkout
Zope and then checkout the CMF package, in the right place.

I'm not sure which of these two approaches is more suitable for which
occasions, but i think between them they should be sufficient to our
purposes.

I can't tell how difficult it is to track my descriptions here - let me
know if i can clarify, and if you see pitfalls.

Ken
klm@zope.com