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

[Chris McDonough]

I was just thinking about the future of the "ZTK", and in the past I have argued 
for not attempting to version the entire set of packages that currently 
comprises Zope 3 over time as "ZTK releases".  Instead, I have argued for 
promoting packages that have some life of their own (independent of the rest of 
the pile) into subprojects that have their own release cycles.  Then outside 
projects such as Plone and Grok could depend on independent versions of such 
packages, giving them slightly more flexibility than requiring a "version of the 
ZTK".

Given that this suggestion has been met with skepticism, let me try another 
tact.  Instead of thinking about it this way, could we think about it as 
*deflating* the current set of zope.* packages that do not currently have a 
meaningful life of their own into a single setuptools distribution named "ZTK". 
  This package would include most everything in zope.app*, plus things like 
zope.server, zope.publisher, and other things that just aren't useful outside of 
Zope-the-appserver, or which currently just depend on "too much".

This "ZTK" distribution would *not* include packages that already have a life of 
their own outside Zope such as zope.interface, zope.component, 
zope.configuration, zope.proxy, ZODB, etc.  These packages would continue to 
have their own release cycles.

Over time, we'd tease out the dependencies of packages that live in the ZTK 
distribution, making them useful outside without any dependency on the ZTK.  The 
names of these packages could be arbitrary (they wouldn't need to retain their 
old "zope.*" names).  Some backwards dependency shims would be added to the ZTK 
to prevent old imports from breaking, and the ZTK distribution would then just 
have a dependency on the thing that got broken out.

I'm thinking that this would simplify things greatly for people who want to be 
consumers of "truly independent" Zope packages.  There'd be exactly N of them 
available for download (where N is much less than 100, more like 20), plus the 
ZTK, which would have the rest of the pile in it over time.  If someone wanted 
to use a forked version of a package that lived in the ZTK distribution, they'd 
either do so by teasing out the dependencies and making it "truly independent" 
or they'd just reroll a custom version of the entire ZTK distribution.

Does this make any sense?

- C


- C