[Grok-dev] grok 1.1alpha release preps
Martijn Faassen
faassen at startifact.com
Mon Nov 16 04:13:18 EST 2009
Hey,
Jan-Wijbrand Kolman wrote:
[snip]
> 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.
+1
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.
http://pypi.python.org/pypi/zodbupdate
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.
Regards,
Martijn
More information about the Grok-dev
mailing list