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

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 Fulton           mailto:[EMAIL PROTECTED]       Python Powered!
CTO                  (540) 361-1714  
Zope Corporation

Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists - )

Reply via email to