[Zope3-dev] Re: lxml / elementtre inclusion

Philipp von Weitershausen philipp at weitershausen.de
Fri May 6 13:08:35 EDT 2005


Jim Fulton wrote:
> 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


More information about the Zope3-dev mailing list