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

[Martijn Faassen]

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 
dependency structures.

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 
something?

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.

Regards,

Martijn