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
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
> 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
> Zope-the-appserver, or which currently just depend on "too much".
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
> 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.
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
> 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.
I don't see why a big package would "simplify things greatly" for you or
> If someone wanted
> 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.
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
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -