[Zope-dev] Adding broken/missing support to zope.interface? (was: experimental.broken - Graceful handling of broken interfaces and components in the ZODB)

[Brian Sutherland]

On Mon, Apr 09, 2012 at 08:15:16PM +0000, Martin Aspeli wrote:
> On 9 April 2012 15:41, Brian Sutherland <brian at vanguardistas.net> wrote:
> 
> > On Sun, Apr 08, 2012 at 01:04:37PM -0700, Ross Patterson wrote:
> > > experimental.broken is working well for me.  It greatly aided me in
> > > getting through a particularly nasty upgrade allowing me to cleanup the
> > > ZCA cruft left by poorly behaved add-ons.  I'd like to proceed with
> > > adding the core of this to zope.interface and I need the
> > > developers/maintainers to weigh in.
> > >
> > > The first and most fundamental matter is changing interface pickles such
> > > that they can be unpickled into something that can fulfill the minimum
> > > interface contract and don't break the ZCA.  To that end, I'd like to
> > > add the following to zope.interface.interface:
> > >
> > >     ...
> > >     try:
> > >         from ZODB.broken import find_global
> > >         from ZODB.broken import IBroken
> > >         def find_interface(modulename, globalname,
> > >                            Broken=IBroken, type=InterfaceClass):
> > >             """
> > >             Find a global interface, returning a broken interface if it
> > can't be found.
> > >             """
> > >             return find_global(modulename, globalname,
> > >                                Broken=IBroken, type=InterfaceClass)
> > >     except ImportError:
> > >         IBroken = Interface
> > >         def find_interface(modulename, globalname,
> > >                            Broken=IBroken, type=InterfaceClass):
> > >             """
> > >             Find a global interface, raising ImportError if it can't be
> > found.
> > >             """
> > >             # From pickle.Unpickler.find_class
> > >             __import__(module)
> > >             mod = sys.modules[module]
> > >             klass = getattr(mod, name)
> > >             return klass
> > >     ...
> > >     class InterfaceClass(Element, InterfaceBase, Specification):
> > >     ...
> > >         def __reduce__(self):
> > >             if self is IBroken:
> > >                 return self.__name__
> > >             return (find_interface, (modulename, globalname))
> > >     ...
> >
> > -1
> >
> > For a number of reasons, but mainly because you add a test dependency on
> > the ZODB from zope.interface. I think that zope.interface is such a
> > fundamental package and the dependency is unacceptable.
> >
> 
> It's a soft dependency only, looking at the code sample.

Soft dependencies are cheating ;)

Cheating is great when you are refactoring old code to try to minimize
dependencies. For new code it's better to just do it right.

> > There has lately been a LOT of work done reducing the dependency
> > structure of zope.* packages. You need a VERY good reason to start
> > reversing that.
> 
> 
>  It doesn't add any more (required) dependencies.

It is required the moment you actually want to write a test for your
code. That means it's pretty much required for development.

Also, if you of the more fanatical sort that believe you should "run
what you test and test what you run" then even a testing dependency is
a real dependency.

> This is a real issue that is breaking the sites of a lot of real users of
> zope.interface in a way that is hard to debug and reverse.

It is quite ridiculous that something as fundamental as zope.interface
needs to have knowledge of a specific database implementation to avoid
problems that are "hard to debug and reverse".

> Can you think of a better way to get around it? Other than "don't get into
> the situation" which isn't a valid answer as long as the ZTK ecosystem
> supports persistent local components.

I'm sorry, having never actually used the ZODB I have absolutely no idea
on what level this could best be implemented.

A question, do you need this code enabled all the time? Or is it
something you only need during specific moments like upgrades?

-- 
Brian Sutherland