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

Jim Fulton jim at zope.com
Thu Apr 15 10:23:29 EDT 2004


Barry Warsaw wrote:
> 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. 

Eactly. Freds work is going to adress this problem.
(I'll restrain myself from going into a tirade about how important this
is for Python. :)

> I've also heard that zope.schema is going away

I thin it will eventually be merged into zope.interface.

 > and that
> the dependency on both zope.i18n and zope.i18nmessageid might not be
> necessary.

Right, maybe

> 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.

We're aware of this problem. That's why we've decoded to make the dependency
data explicit (manually created) rather than implicit (automatically created).

Each separately distributed package will have a DEPENDENCIES.cfg that is
created by hand and that *constrains* dependencies on other packages. It
makes explicit the intended dependencies. Dependencies not listed here
are bugs.  Adding depenencies to this file should be considered a big deal.

> 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.

Probably neither.  I doubt that there will ever be a standard Python
interface system.  I'm not going to hold my breath.  Guido argued
for having Zope's interfaces be in s subpackage (or have a weird name)
specifically to make it easier to add a standard interface package later,
assuming that a standard package might not be exactly the same as Zope's.

> 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

We've had colisions in the past. That's why we're being careful now.

(BTW, I think it was a mistake to have top-level persistent and transaction
packages. I think that will eventually come back to haunt us.)

The only way to avoid collissions is to pick stupid names (zthis, zthat).
I much prefer z.this to zthis. This assumes that we can make it easy to
install z.this into z.

 > so I'd opt
> for an approach that gets the non-Zope specific technologies into the
> most hands of Python programmers.

I think that that's a different discussion.  The safest thing to do
for now is to continue using a container package.

Jim

-- 
Jim Fulton           mailto:jim at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org




More information about the Zope-Dev mailing list