[Zope-dev] "ZTK" futures: one big package?

Martijn Faassen faassen at startifact.com
Wed May 13 09:59:31 EDT 2009

Hey Chris,

Chris McDonough wrote:
> On 5/12/09 4:44 AM, Patrick Gerken wrote:
> I don't think there will ever be a point where it's "finished"; at least not in 
> any time frame in which Zope is still relevant at the end.  Sure, we can keep 
> the current setuptools distributions and keep pulling apart their respective 
> dependencies forever, but by the time it's all over, it just won't matter 
> anyway; folks will be happily using "Django 3000" or "Pylons 4", which will have 
> recreated all the features we teased out.

Such skepticism. Please consult the following (non-reduced) dependency 
graphs (of released packages):


I've picked a few high-level components like container and catalog. They 
depend on a lot, yes. Too much, yes, there are bits that can still be 
teased out from that graph (in particular I think we should make the 
container stop depending on the publisher). But they also depend on a 
lot because they're fairly high-level components that do quite a few things.

I realize that many of these packages are not useful for a random Python 
developer. But I don't believe we have to ensure all our packages are 
useful in that way. We just have to create more of them.

I think all of the ZMI stuff should either be eliminated or 
consolidated. That would allow us to lose zope.app.* packages. Remove 
them from PyPI, no, though - we already crossed that bridge and can't 
break everybody's code.

I think these high-level components and a few more is what we can at 
least base a future release of Grok around. (with a compat package that 
pulls in a lot of the zope.app. packages to make sure the existing code 
doesn't break). The dependency graph will still be huge, but it won't be 
as crazy as it is with the current Grok release.



More information about the Zope-Dev mailing list