[Zope3-dev] Re: [Zope-dev] Re: More arguments for "z" (was Re: Zope and zope)

[Barry Warsaw]

On Thu, 2004-04-15 at 09:25, Jim Fulton wrote:

>  From the zope package README.txt:
> 
>    "Zope Project Packages
> 
>    The zope package is a pure namespace package holding packages developed as
>    part of the Zope 3 project.
> 
>    Generally, the immediate subpackages of the zope package should be
>    useful and usable outside of the Zope application server.  Subpackages
>    of the zope package should have minimal interdependencies, although
>    most depend on zope.interfaces.

Speaking as someone who's tried to use zope subpackages outside of z3,
there are practical problems with this.  About 8 months ago, I tried to
pull ZPT, et al out to use as a standalone version.  I ended up having
to grab zope.interfaces, zope.pagetemplates, zope.tal, zope.tales, and
zope.i18n.  All make sense (especially since I wanted internationalized
ZPT), but tracking all the dependencies were difficult.  I tried to
update all that again a few weeks ago and found that I also now needed
zope.i18nmessageid and zope.schema.

It looks like Fred's packaging work will help with the very tricky task
of figuring out the dependencies and creating distutils packages for the
desired stuff.  I've also heard that zope.schema is going away and that
the dependency on both zope.i18n and zope.i18nmessageid might not be
necessary.

But I'm still concerned that there will be creeping dependencies among
more things inside the zope package, making it harder to use some of
those technologies independently.  E.g. there are several standalone ZPT
implementations in the wild, but I happen to think z3's is the best and
would like to see it adopted more widely in the Python world.

Also, for a long time I've wanted to see z3's interfaces package be used
outside Zope3, perhaps even being adopted as a standard library package
eventually.  I wonder if living inside the zope container package helps
or hurts those prospects.

I understand the desire to carve out a package namespace that z3 can
reliably use without risk of collision with other packages.  I still
think that's less of a practical concern in the Python world so I'd opt
for an approach that gets the non-Zope specific technologies into the
most hands of Python programmers.

-Barry