[Grok-dev] grok 1.1alpha release preps

Martijn Faassen faassen at startifact.com
Mon Nov 16 04:13:18 EST 2009


Jan-Wijbrand Kolman wrote:
> I have an issue though:
> Grok (and the grokcore.* family too probably) contains still quite some 
> imports from "deprecated" packages. For example from zope.app.container, 
> zope.app.folder, zope.app.intids, etc. etc.
> In my opinion we should try to get rid of these "deprecated" imports.


Otherwise the exercise isn't worth as much. The idea is that we can 
decrease our dependencies significantly by using the ZTK.

That said, we could do this in the context of an a2.

> Questions (again):
> 1) Do people think we should try to get rid of these imports for the 1.1 
> release? Personally I would like to...

Definitely before 1.1 is released. We should base Grok and grokcore.* 
only on packages actually in the non-deprecated ZTK if at all possible.

> 2) To what extend could changing these imports (and thus potentially 
> lifting dependencies) have repercussions on persistent objects? We 
> should be careful I guess about this.

Good question. I think the impact should be minimal for things that Grok 
defines itself, however, as those classes don't change. I don't know 
whether there are many persistent things that Grok imports but does not 
subclass itself - those are more problematic.

If we have that situation, we should provide a "compatibility package", 
which provides the deprecated packages as dependencies too, that can be 
optionally installed.

People should then be able to run 'zodbupdate' and afterwards hopefully 
be able to uninstall the compatibility package.


This helps with those cases where you have a persistent object that 
refers to a class in a compatibility package, but this class is now in 
fact imported from another place. The ZODB will be modified so that it 
refers to that class in the new place directly.

This process should of course be documented well.



More information about the Grok-dev mailing list