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