[Grok-dev] Re: releasing 0.12.1

[Philipp von Weitershausen]

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, 
> right?

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 
content-specific, though.

> 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 
the following:

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.