[Zope-dev] "ZTK" futures: one big package?
faassen at startifact.com
Wed May 13 09:08:44 EDT 2009
Chris McDonough wrote:
> Another thing is this: even if we're successful in teasing out dependency info
> so we do have a collection of truly independently useful things, after it's all
> over, we're going to get to a point one way or another where we make a big
> package of stuff that just can't have its dependencies teased apart because it
> *really is just one thing*. Why *not* just do it now?
That's why I suggest a ZMI project (or doing away with the ZMI entirely
if nobody's interested). That's really the main thing creating entangled
I want to create a grokcore.view that doesn't depend on a thousand Zope
packages and a ton of Zope code. That's because grokcore.view doesn't
need all this stuff. Right now it gets it indirectly through tangled
dependencies. We need to try porting it to the latest set of releases
and see whether that helps. Once that's done, we need to cut a few more
dependencies, and there we are.
If all those packages are maintained as a single large ball, I cannot do
this analysis. In the current setting, we have experience with this
analysis, we have tools to do this analysis. Additionally, I'd need to
do a lot of work separating things again in order to release
grokcore.view if I were to do the work in a singly maintained ball.
But you also said that there's no need to maintain this *just* as a
single ball. That is, we could have something similar to the current
Zope 3 project that pulls in all the other packages as externals and
that we release to PyPI.
I'm not sure what this gains us currently. Who would be using this
package? Are you suggesting we remove all the other stuff from PyPI or
Finally, an independent package can be useful by itself, with clear
dependency structures, even though it's only useful for people who buy
into quite a few of the other packages that you don't want to buy into.
Such is the case for zope.site.
More information about the Zope-Dev