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