[Zope3-dev] Spaghetti-hunting

[Barry A. Warsaw]

>>>>> "SH" == Shane Hathaway <shane@zope.com> writes:

    SH> Very true.  In Zope 3, that is the distinction between the
    SH> "Zope" package and the "Zope.App" package.  Every Zope.*
    SH> package, besides Zope.App.*, can be used independently of
    SH> Zope.  So Zope.Publisher, Zope.Server, Zope.TAL,
    SH> Zope.PageTemplate, Zope.ContextWrapper, etc. are all
    SH> non-interdependent.

This touches on something I've been thinking about for Mailman3
actually, although I haven't gotten very far in prototyping it.

The idea is that the bulk of an application can be put together by
standard distutils-style packages, which you'd either install in the
standard site-packages directory, or (using distutils options) in an
unrelated "lib" directory.  The latter would of course require you to
fiddle with sys.path to get things to work, but that would be doable.

So then, you're left with a bunch of driver scripts and other
entryways and glue programs that interface with the external systems
you want to integrate to.  In Mailman's case, that would be a bunch of
cron, command-line, mail, and cgi programs.

For Zope3, the idea is that all those packages that are independent
ought to be wrapped in distutils for independent use outside of Zope.
It doesn't matter if, as Fred points out, there are some /clean/
interdependencies.  IOW, if PageTemplate is dependent on TAL, that's
fine, as long as TAL isn't dependent on PageTemplate.  It's not much
different IMO than the Mailman package being dependent on having the
email package available.

You could imagine then, that installing Zope would be as easy as
running "python setup.py install" for a slew of packages, then having
instructions on how to invoke the top level scripts and install your
own content and add on packages.  In fact, Zope.App would be the same
deal, and any third party Zope products should just distutils install
into a special directory
(e.g. /usr/local/lib/python2.2/site-packages/Zope/App).

There may be alternative "sumo" distributions of Zope3 then, where it
installs the world into a special site-packages-like directory that's
outside the normal Python extension mechanism.  This can be
accomplished through distutils' --install-lib option.  FWIW, I do this
in Mailman 2.1 for the email, JapaneseCodecs, and KoreanCodecs
packages (I install them in $prefix/pythonlib instead of
.../pythonX.Y/site-packages).

I think this approach opens the possibility for much more code reuse
of Python applications, by integrating into the standard Python
extension mechanisms.  For the Mailman situation, I could easily see
people writing their own web gui's or other applications on top of the
Mailman package (it's been talked about in the MM discussion lists).

For Zope-derived software, I can easily see how other Python
applications might like to use TAL, PageTemplate, etc.  These should
probably be top-level package names, and not be in the Zope.*
namespace.  Then, you could distutils install them and any Python app
could just use "import TAL".

Thoughts?
-Barry