launchpad-dev team mailing list archive

[Danilo Šegan <danilo@xxxxxxxxxxxxx>]

У пет, 01. 10 2010. у 11:48 +0200, Henning Eggers пише:
> Am 30.09.2010 18:25, schrieb Curtis Hovey:
> > Hi Henning.
> > 
> > On Thu, 2010-09-30 at 17:46 +0200, Henning Eggers wrote:
> >> So, I am trying to land this branch:
> >> https://code.launchpad.net/~henninge/launchpad/devel-remove-c-l-i/+merge/37116
> >>
> >> One change is this:
> >> http://paste.ubuntu.com/503337/
> >>
> >> Running ec2 test gives me this error:
> >> http://paste.ubuntu.com/503335/
> > 
> >> Does anybody have a clue what is to be done here?
> > 
> > :( I have a lot of experience with this kind of situation and very
> > little success. I have had only 50% success rate at removing
> > canonical.launchpad.interfaces issues.
> 
> That does not sound very encouraging. Also, it does not answer my question
> because I don't fully understand what is going on here. Why is the import
> through c.l.i not causing any problems while the direct import does?

>  What is _schema_circular_imports.py's role in this?

Afaik, _schema_circular_imports is used to enable some interface
definitions for web service API.  Since for web service exports we
commonly need to define what type a field is, it's quite common to have
two interfaces reference each other (for instance, IPOTemplate and
IPOFile).  That leads to an unresolvable circular imports hell. (Note
that this is not specific to web service stuff: it just got exacerbated
by it.)

Solution is to simply not declare the real interfaces, but instead
"patch" the interface later (in _schema_circular_imports.py).

As such, you can track where the problematic IPerson import is
happening, replace it with "Interface" instead, and patch it in
_schema_circular_imports.  Not sure it's going to help, but if you can
actually import IPerson first (as Curtis suggested), that might be
useful as well.

> > IPerson is a in high demand. Try making it the first in the list.
> 
> Sorry, which list? List of imports, I understand that, but where? I am not
> even importing IPerson ...

Import it before importing IPersonSet (which ends up circularly
depending on IPerson and thus re-imports entire person module), I think.

Cheers,
Danilo