Martijn Faassen wrote:

If someone that is not interested in Zope 3 in the first place wrote a Python library we'd like to include, the relicensing hurdle will be larger, though. What's to be done with Twisted integration, for instance?

Relying on new external libraries with the core of Zope 3 will always be a big step. Then again, I also think that this way large amount of new features can be made available to Zope 3 without us having to reinvent wheels. It makes Zope 3 a more open platform. Perhaps the procedure for adopting externally written code should be spelled out. There are quite a few shapes this could take (external library, included in Zope 3 tree), and right now it seems nobody but Jim knows what is required, or whether such inclusion is allowable at all in the first place.

We can and often do include 3rd-party non-ZPL software. So it is certainly possible.

Currently, I'd prefer that ZC employees check such 3rd-party code in.
The current system isn't great, but I can't think of a better one.

In any case, I hope to address this in the future by defining a Zope
core that is much smaller and making it much easier to add 3rd-party
packages to an installed base Zope or, perhaps, make it easier to
assemble Zope distributions by combining the core with 3rd-party
add-ons for convenience.  Obviously, the prototyping we've done
with zpkgtools is aimed at this.

I do think, however, that XML facilities of the sort offered by lxml
now, or in the future, should be a core feature of Zope 3, if or
no other reason than so we can use them in tests. :)


Jim Fulton           mailto:[EMAIL PROTECTED]       Python Powered!
CTO                  (540) 361-1714  
Zope Corporation
Zope3-dev mailing list

Reply via email to