[Zope-dev] who wants to maintain Zope 3?

[Chris McDonough]

On 4/12/09 12:02 AM, Tim Hoffman wrote:
> Hi Chris
>
> On Sun, Apr 12, 2009 at 11:55 AM, Chris McDonough<chrism at plope.com>  wrote:
>> On 4/11/09 11:49 PM, Tim Hoffman wrote:
>>> Ok so pretty much the same as the traditional Zope 3 model.
>>>
>>> Are you still using the 'c' based zope.security or built your own.
>> We don't depend on zope.security and there is no C in the BFG security code
>> itself.
>>
>>> On a side note I have got a big chunk of zope3 running on gae (had to
>>> gut zope.security and zope.proxy) and plan on revisiting the whole
>>> effort looking at bfg, but I would need to revert
>>> to zpt because cheetah
>> Chameleon, I think you mean.
>>
>
> Oops yeah! ;)
>
>
>>> is dependant on lxml and its no 'c' for me,
>>> any suggestions or ideas
>>> on the effort involved.  (I have zpt running with similiar
>>> functionality  to zope.app.pagetemplate level rather thatn
>>> zope.pagetemplate) with full macro lookups etc....
>> Malthe has expressed interest in removing the lxml dependency from
>> Chameleon, but I think he needs funding.  Others have also expressed an
>> interest in this and we'd probably kick in to a pool of funds towards this
>> if you ever get to a point where it became something you wanted to do.  I
>> really don't know how much effort is involved, but for the record, Chameleon
>> only depends relatively shallowly on lxml (mostly for xpath expressions),
>> and removing lxml will make no difference in rendering speed.
>
>
> ok but I assume it's not too much of a problem to swap out chameleon
> altogther  in the meantime and go back to zpt (unfortunately I don't
> have money for this project ;-(

Yeah, that's really no problem.  As long as you have C-free versions of 
zope.interface and zope.proxy laying around already (which is really just a 
matter of preventing those packages' C code from compiling I think), getting BFG 
running on GAE without Chameleon really just should be a matter of removing the 
lxml dependency from the setup.py of bfg itself.

> Again thanks for the info.
>
> My plan to is to rollout a small site I am building in zope3 on gae,
> and then go back
> and do a major refactor on what I have learnt, and look at bfg as the
> model going forward.

Sounds like a plan... I hope to learn from what you do to get rid of some 
non-lxml C dependencies we have too (ala zope.interface, zope.proxy, 
zope.hookable, zope.i18nmessageid, etc); maybe we can fold some of this work 
into the normal or alternate version of these packages.

- C