[Zope-dev] "ZTK" futures: one big package?
chris at simplistix.co.uk
Sun May 10 20:50:58 EDT 2009
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.
Simplistix - Content Management, Zope & Python Consulting
More information about the Zope-Dev