[Grok-dev] Re: releasing 0.12.1
Philipp von Weitershausen
philipp at weitershausen.de
Sat Jun 7 16:57:24 EDT 2008
Martijn Faassen wrote:
> Wichert Akkerman wrote:
>> Previously Martijn Faassen wrote:
>>> Philipp von Weitershausen wrote:
>>>> On 4 Jun 2008, at 15:25 , Sebastian Ware wrote:
>>>>> Could someone show me what a module alias looks like? I have
>>>>> googled but not found any example.
>>>> import the.new.module
>>>> sys.modules['old.module'] = the.new.module
>>> The dots imply that this works with namespace packages, does it? Or
>>> do you have to create 'old' first and then 'module'?
>>> I wonder whether we cannot provide some infrastructure that will help
>>> with this very common migration case.
>> You mean like zope.deprecate does?
> zope.deprecation deals with moving around APIs though, not content,
zope.deprecation can deprecate whole modules, but it doesn't create
aliases (you have to create the alias yourself, and instead of linking
it to the original module, you link it to a deprecation wrapper around
the original module). Maybe you're talking about
zope.deferredimport.deprecated()? This is somewhat about creating
aliases, though it's more like a BBB import than anything else (it's
really a BBB improt that raises a deprecation warning upon import).
Both zope.deprecation and zope.deferredimport aren't very API- nor
> It'd be a good package to try to extend to support
> content-upgrades for classes that moves around, though. Or perhaps I'm
> missing something about it?
This isn't so much about deprecation, it's about providing module
aliases for persistent objects (rather than raising warnings about API
usage). This is a non-trivial thing to do automatically. Off the top of
my head I can only think of ZODB's broken hook. Whenever ZODB encounters
a pickle that it can't deserialize to an instance of a class (IOW, it
doesn't find the class), it'll use the broken hook. In a standard Zope 3
environment, zope.app.broken fills that hook. Grok could fill it, too,
and through some magic determine whether a grok.Model instance is
involved and then perhaps *somehow* track where it moved... Yes, I'm
waving my hands here :)
So, doing it automatically isn't easy. Besides that, I don't see how
much we need helping. If we do it manually, you have to keep track of
where you moved your classes anyway. And then you just need to do one of
a) introduce a module alias (if you've moved a whole module)
b) or provide BBB imports in the old module
Both aren't hard, in fact b) is pretty straight-forward. I don't think
it gets any easier. You just have to *know* that you have to do it.
That's really the trickiest part, I think.
More information about the Grok-dev