[Zope3-dev] Voting on Schema design

[Barry A. Warsaw]

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

    SH> Here is the theory as I see it.

I really hate to get dragged into this one again, but Shane's
invitiation is so appealing, I can't resist. ;)

    SH> Zope consists of a large number of independently reusable
    SH> packages--so many that installing directly to site-packages
    SH> would cause a burden. Zope 3 will have even more reusable
    SH> packages.  Therefore Zope 3 uses a top-level package called
    SH> Zope, but the top-level package functions only as a
    SH> *namespace*.  This is very similar to Java's package naming
    SH> convention, but we're not using an "org" prefix.

    SH> Thus the presence of, say, Zope.ComponentArchitecture, does
    SH> not imply the presence of Zope.PageTemplate, even though both
    SH> are distributed with Zope.  Nor should Zope.PageTemplate
    SH> expect to find Zope.ComponentArchitecture.  Developers will be
    SH> able to select only the parts they need from Zope.*, while at
    SH> the same time, installing Zope won't flood site-packages.

First let's separate some concerns:

I think we all agree that installing Zope should never install
anything in site-packages.  If we decide to organize Zope's packages
around distutils, then we're fine because distutils is rich enough to
install packages in alternative locations.

I'm primarily concerned here with the utility of packages developed
under the Zope umbrella, used in non-Zope projects, e.g. PageTemplates
or ComponentArchitecture or TAL or whatever.  These would be
distributed as distutils tarballs, with (at least) these two use
cases:

- Joe Hacker decides that he'd love to use PageTemplates in his own
  scripts on his own machine.  He'd use "python setup.py install" to
  stick it in his own site-packages.

- Jimmy Projectmanager decides that he'd love to use PageTemplates in
  his Frobnitz project, but he's confronted with the same issue that
  Zope is: installing Frobnitz should not install things to
  site-packages.  So he uses a slightly more verbose invocation of
  "python setup.py install" to unpack the PageTemplates tarball into
  some subdirectory under /usr/local/frobnitz.

Jimmy's motivation is simple: he cannot trust the version of
PageTemplates that might already be in site-packages, and he does not
want Joe to complain to him that an installation of Frobnitz screwed
up his custom scripts.  s/Frobnitz/Zope/ and we have the exact same
motivation.

I'm not at all concerned about namespace pollution because 1) I doubt
that in practice there will be name collisions on packages like
"PageTemplates", "ComponentArchitecture", and "TAL".  I might be a
little more worried about something named "DateTime" but even there, I
think a first-come-first-served approach will be fine in practice for
a long time.  Besides, this is primarily a concern for the Joe Hacker
use case.  2) For the Jimmy Projectmanager use case, he controls the
final installed location and name of the packages he's co-bundling
with Frobnitz, so if there /is/ a collision, it can be dealt with
fairly easily using standard distutils tools.

So the question of whether to lump independent packages under a top
level "Zope" package is really one of advertising <wink>.  I
personally think it will make it a bit less convenient to distribute
Zope developed packages under the "Zope" top-level package name, and
that promoting some of the more useful independent packages out of the
"Zope" package namespace would better promote their use within the
wider Python community.  You (or the Zope Pope :) could disagree with
this opinion, or want to promote the Zope brand by keeping them in the
Zope package, and that would be fine, but I see little technical
reason for the choice of a Zope top-level package.

-Barry