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.
The question is whether we always need to check it into our svn. pytz, for example, is a separate package that we just had to make ZPL and check it in, instead of simply just bundling it loosely. I expect this sort of thing will sooner or later get us into trouble with package maintainers that need to maintain (e.g. Debian) packages for both pytz and Zope and thus will inevitably run into conflicts.
With twisted, we have at least found a sensible approach using svn:externals. I realize that such an approach isn't always workable (e.g. with pytz), but I don't think the ultimate solution is Zope 3 "inhaling" projects. As for lxml, I would like to see this as a loose coupling / package requirement as twisted will once be, too.
As for the dependencies on libxml etc., I don't think this isn't much of an issue for now since lxml is still 0.x and months away from being included into Zope 3 officially. So, neither lxml nor Zope 3 are even there yet...
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.
Great.
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. :)
+1
Philipp _______________________________________________ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
