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
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.
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 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists - http://mail.zope.org/mailman/listinfo/zope-announce