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
> This "ZTK" distribution would *not* include packages that already have a life
> 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.
> names of these packages could be arbitrary (they wouldn't need to retain
> old "zope.*" names). Some backwards dependency shims would be added to the
> to prevent old imports from breaking, and the ZTK distribution would then
> 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
> 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
> ZTK, which would have the rest of the pile in it over time. If someone
> to use a forked version of a package that lived in the ZTK distribution,
> either do so by teasing out the dependencies and making it "truly
> or they'd just reroll a custom version of the entire ZTK distribution.
> Does this make any sense?
yes, totally in agreement.
Simplistix - Content Management, Zope & Python Consulting
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -