Chris McDonough wrote:
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 "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.
Yay! Big +1 from me...
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.
Well, if they just used their old zope.* names, no shims would be needed, right? If it works, don't break it so it doesn't work ;-)
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?
yes, totally in agreement. Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk