Re: zope29 components

[Brook Milligan <brook%biology.nmsu.edu@localhost>]

Takahiro Kambe writes:
 > It isn't direct answer for your question, here is a matrix Python,
 > Plone, Zope and ZODB's release.
 > 
 >        Plone     Zope           Python       ZODB
 >        2.0.5 2.7.0-2.7.9     2.3.4-2.3.5     3.2
 >        2.1.3 2.7.0-2.7.9     2.3.4-2.3.5     3.2
 >        2.1.3 2.8.0-2.8.8     2.3.4-2.3.5     3.4 (MVCC)
 >        2.5.0 2.8.7-          2.3.4-2.3.5     3.4 (MVCC)
 >        2.5.0 2.9.3-          2.4.2-2.4.3     3.6 (MVCC)

>From this and a brief review of zope, it seems like we have the
following situation:

- multiple versions of zope which could (and might need to) coexist

- a set of dependent zope packages, each of which has its own
  requirements for zope version, some of which could potentially be
  deployed within multiple versions of zope or zope instances

- multiple versions of plone, each of which depend on certain zope
  versions and could potentially be deployed within multiple
  coexisting versions of zope or zope instances

- a set of plone products, each of which has its own requirements for
  plone version, some of which could potentially be deployed within
  multiple versions of plone (zope).

Note that it might be necessary for a site to have several coexisting
zope versions.  This could occur, for example, when multiple zope
instances require different sets of packages/products and the
dependencies cannot be satisfied by a single version of zope.
Consequently, it seems that we must handle coexistence of zope
versions and installation of packages/products into multiple zope
versions.  (Or identify a mechanism for deploying an installed
package/product into a specific instance of zope.)

Perhaps this can be handled in the following way:

- a series of www/zopeXXX packages with appropriate versions.

- a mk/zope.mk file with logic to select a default version, set
  variables like the installation base directory, etc.

- a www/zope package that simply installs the default version and
  provides makefile fragments to simplify the installation of
  packages/products.

- each zope package would have a www/zope-XXX package that defines
  variables like ZOPE_VERSION_REQUIRED and uses www/zope/package.mk
  and mk/zope.mk to define dependencies.

- a series of www/ploneXXX packages with appropriate versions and
  definitions of ZOPE_VERSION_REQUIRED

- a mk/plone.mk file similar to mk/zope.mk

- a www/plone package that is analogous to www/zope; i.e., it installs
  the default version of plone (and its dependent zope) and provides
  makefile fragments to simplify the installation of plone products.

- each plone package would have a www/plone-XXX package that defines
  variables like PLONE_VERSION_REQUIRED and uses www/plone/product.mk
  and mk/plone.mk to define dependencies.

- creation of a zope instance would involve the current process as
  well as deployment of all appropriate installed zope packages and
  plone products.

I am throwing this out in the spirit of starting a discussion that
will lead to a coherent means of handling the web of dependencies that
exists within zope and plone.  Currently, pkgsrc cannot be used as a
means of deploying a fully capable up-to-date zope/plone site.  My
hope is that some discussion of these issues will lead to a concrete
plan that can be rapidly implemented within pkgsrc.

Let the discussion begin.

Cheers,
Brook