zope.app.keyreference, zope.app.intid and zope.app.catalog
While you guys are moving zope.app.container to zope.container and those cleaning many dependencies, I'd also like to clean intid/catalog related stuff. The whole thing consists of three main packages that can be cleaned: * zope.app.keyreference - it doesn't depend on any ZMI or container stuff, it's just a simple package defining the IKeyReference interface and implementing it for persistent objects. I'd like to rename the package to just zope.keyreference (and making z.a.keyreference depend on it). * zope.app.intid - this one depends on container stuff, because of events and also defines some ZMI views. The events are not a problem anymore, because we have zope.container now, but the ZMI stuff requires zope.app.publisher (though it's not in direct requirements for some reason). I'd like to move all stuff except browser pages to the zope.intid package. * zope.app.catalog - pretty the same story as zope.app.intid, but it also uses zope.app.form's auto-form-directives. I'd like to move the non-ZMI code to plain zope.catalog. However, it's still not clear to me what should we do with old imports and pickled objects (there are "over 9000" of them in case of key-references). I'd like to make non-deprecated backward-compatibilty imports in the old places until we have a generic and easy-to-use tool for "touching" ZODB objects. Suggestions/objections? -- WBR, Dan Korostelev
Hi, On Sat, 31 Jan 2009 13:59:52 +0300 Dan Korostelev <nadako@gmail.com> wrote:
While you guys are moving zope.app.container to zope.container and those cleaning many dependencies, I'd also like to clean intid/catalog related stuff. The whole thing consists of three main packages that can be cleaned:
* zope.app.keyreference - it doesn't depend on any ZMI or container stuff, it's just a simple package defining the IKeyReference interface and implementing it for persistent objects. I'd like to rename the package to just zope.keyreference (and making z.a.keyreference depend on it).
* zope.app.intid - this one depends on container stuff, because of events and also defines some ZMI views. The events are not a problem anymore, because we have zope.container now, but the ZMI stuff requires zope.app.publisher (though it's not in direct requirements for some reason). I'd like to move all stuff except browser pages to the zope.intid package.
* zope.app.catalog - pretty the same story as zope.app.intid, but it also uses zope.app.form's auto-form-directives. I'd like to move the non-ZMI code to plain zope.catalog.
However, it's still not clear to me what should we do with old imports and pickled objects (there are "over 9000" of them in case of key-references). I'd like to make non-deprecated backward-compatibilty imports in the old places until we have a generic and easy-to-use tool for "touching" ZODB objects.
Thanks for picking those up. The suggestions are pretty much like what we've been following: split out the non-ZMI parts from zope.app.* into zope.* packages. WRT the ZODB issues: I've started working on a 'touch' tool for ZODB that analyzes (pickle-based) storages for class references which are missing in your code base and (if all class references exist) can touch all objects that reference classes from indirect imports. Just a note: Martijn and I are currently trying to stabilize the zope.* trunks to get releases out. I think we should try to avoid stepping on each others toes here. Christian -- Christian Theune · ct@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 7 · fax +49 345 1229889 1 Zope and Plone consulting and development
2009/1/31 Christian Theune <ct@gocept.com>:
WRT the ZODB issues: I've started working on a 'touch' tool for ZODB that analyzes (pickle-based) storages for class references which are missing in your code base and (if all class references exist) can touch all objects that reference classes from indirect imports.
Yeah, I saw some commits on that thing. Looking forward for it to be developed!
Just a note: Martijn and I are currently trying to stabilize the zope.* trunks to get releases out. I think we should try to avoid stepping on each others toes here.
Well, I chose packages that are kind of separated from most of "zope the application" packages, because there aren't many packages that depend on either zope.app.catalog or zope.app.intid/keyreference. So I think we can do that work at the same time. However, it may be better to wait for zope.container to be released before starting working on intid and catalog? -- WBR, Dan Korostelev
Hi, On Sat, 31 Jan 2009 15:11:44 +0300 Dan Korostelev <nadako@gmail.com> wrote:
2009/1/31 Christian Theune <ct@gocept.com>:
WRT the ZODB issues: I've started working on a 'touch' tool for ZODB that analyzes (pickle-based) storages for class references which are missing in your code base and (if all class references exist) can touch all objects that reference classes from indirect imports.
Yeah, I saw some commits on that thing. Looking forward for it to be developed!
Just a note: Martijn and I are currently trying to stabilize the zope.* trunks to get releases out. I think we should try to avoid stepping on each others toes here.
Well, I chose packages that are kind of separated from most of "zope the application" packages, because there aren't many packages that depend on either zope.app.catalog or zope.app.intid/keyreference. So I think we can do that work at the same time. However, it may be better to wait for zope.container to be released before starting working on intid and catalog?
I'm just trying to be defensive on the release front. We're trying to get our changes released ASAP and I'd just like to avoid having some packages not in a releasable state at that point. OTOH we're kind of stuck as we're mostly disassembling right now ... grml. Martijn? What do you say? Christian -- Christian Theune · ct@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 7 · fax +49 345 1229889 1 Zope and Plone consulting and development
Hey, Dan Korostelev wrote:
Well, I chose packages that are kind of separated from most of "zope the application" packages, because there aren't many packages that depend on either zope.app.catalog or zope.app.intid/keyreference. So I think we can do that work at the same time. However, it may be better to wait for zope.container to be released before starting working on intid and catalog?
I think it's fine to start the work, but on a branch if you want to check in, or if you want to check into their trunks, please wait until we let you know we're done (later today). We're going to do a lot of releases today as we touched a lot of packages and without releases many buildouts are currently broken (unless you basically put all the Zope 3 packages on the 'develop' line, which is what z3c.recipe.compattest can do for you, more or less, by creating test runners). Anyway, so please do your work by all means, but it'd be helpful if you could not touch their trunks for the time being. Regards, Martijn
2009/1/31 Martijn Faassen <faassen@startifact.com>:
Dan Korostelev wrote:
Well, I chose packages that are kind of separated from most of "zope the application" packages, because there aren't many packages that depend on either zope.app.catalog or zope.app.intid/keyreference. So I think we can do that work at the same time. However, it may be better to wait for zope.container to be released before starting working on intid and catalog?
I think it's fine to start the work, but on a branch if you want to check in, or if you want to check into their trunks, please wait until we let you know we're done (later today).
We're going to do a lot of releases today as we touched a lot of packages and without releases many buildouts are currently broken (unless you basically put all the Zope 3 packages on the 'develop' line, which is what z3c.recipe.compattest can do for you, more or less, by creating test runners).
Anyway, so please do your work by all means, but it'd be helpful if you could not touch their trunks for the time being.
I already committed a new "zope.keyreference" package that is very little and it has all its tests pass, so I think it's not a problem. However, I'll stop now, and won't touch original zope.app.keyreference until you get your work done. I'll check out the z3c.recipe.compattest for now:) Good luck with your great work! -- WBR, Dan Korostelev
Hey, [snip plan to clean up more dependencies] Awesome! As Christian said, this is pretty much what we've been doing. You might want to mess around with z3c.recipe.compattest to run compatibility tests after your changes, though it's still a bit finicky and rather slow. But if you try it out, please let the list know about any problems. Regards, Martijn
Hey, I've released our changes in zope.app.intid. We hadn't touched zope.app.catalog and zope.app.keyreference. Anyway, the trunks are yours. Regards, Martijn
participants (3)
-
Christian Theune -
Dan Korostelev -
Martijn Faassen