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

[Martijn Faassen]

Hey,

Chris McDonough wrote:

 > Instead, I have argued for promoting packages that have some life of
 > their own (independent of the rest of the pile) into subprojects that
 > have their own release cycles.

 > Then outside projects such as Plone and Grok could depend on
 > independent versions of such packages, giving them slightly more
 > flexibility than requiring a "version of the ZTK".

We already have that flexibility today. To me, the utility of a release 
of version numbers in the ZTK does not at all exclude the potential to 
evolve the packages to more independent sub-projects.

> Given that this suggestion has been met with skepticism, let me try another 
> tact. 

I think that's an inaccurate description of the response you got. I'm 
quite positive about trying to give as many packages as possible a life 
of their own. I don't think you got anyone else arguing against this 
point of view.

I'm also quite positive that some packages are:

* useful as independently distributed packages

* only make sense in a Zope 3 or a Grok or a Zope 2 context, i.e. they 
depend on a significant set of Zope packages.

I'd like to get out of this paradigm:

* the Zope packages are independent sub-projects.

* therefore we cannot distribute a list of versions that work best together.

And this one:

* if we distribute a KGS of anything

* packages in that anything aren't independently reusable automatically 
and should be merged into a ball.

I'd also like to get out of the following paradigm:

* the Zope packages are not independently reusable yet

* therefore we should distribute them all together

We're in a grey area. Some package are here, some packages are there, 
some are in between. Some packages build on other packages, but have 
clear dependency structures. Some don't have clear dependency 
structures. Some have better documentation and better focus than others.

If there is to be a merging of code together, then I propose we continue 
the project where the ZMI code is merged into one or a few packages. We 
can also investigate merging 2 or 3 packages together where it seems to 
make sense, or simply moving code between packages (some code needs to 
go down the dependency list, some up).

> 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 package would include most everything in zope.app*, plus things like 
> zope.server, zope.publisher, and other things that just aren't useful outside of 
> Zope-the-appserver, or which currently just depend on "too much".

-1

This would make it a lot harder to:

* clean up dependency relationships with the goal of creating more 
reusable code. We'd all hide them in a sumo ball again.

* get rid of bits we *don't want anymore*. If I need anything in a sumo 
package I'd need *all* of it.

* override individual packages with newer versions

* we've done a lot of refactoring recently trying to separate the UI 
from packages. This is done by creating a *new* package, leaving the old 
package behind. We can do this, test this and release this 
package-by-package now.

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

I don't like the attempt to redefine what the ZTK means to a giant ball 
of Python packages. That's implying that, say, zope.component is *not* 
in the ZTK. That's wrong.

Why generate a whole lot of work for ourselves getting from where we are 
now to here? We've learned how to work with the current situation in 
2007 already.

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

I don't see why a big package would "simplify things greatly" for you or 
anyone else.

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

And that's easier than the current situation how? Are you really 
proposing we destroy the dependency information we've already teased out 
and then make people do the work again?

> Does this make any sense?

Not a lot in my book.

I think an important reason why there's so much awareness of dependency 
issues in the Zope world now (and effort spent on it) is precisely 
because we released our separate packages and can see the dependency 
information clearly.

Regards,

Martijn