From: Mark H. <mha...@sk...> - 2011-10-21 06:47:50
|
On 21/10/2011 1:22 PM, Jason Heeris wrote: > On 20 October 2011 20:26, Mark Hammond<mha...@sk...> wrote: >> but if you (or anyone) can turn that >> into a failing py2exe program, I'll fix it - or at least determine a >> work-around :) > > Okay, you can see the code here: https://github.com/detly/Py2exe-Test > > At the moment it fails to build altogether, and it's probably a dumb > mistake on my part. The build log shows: ... I've pushed a clone at https://github.com/mhammond/Py2exe-Test which demonstrates the same problem. Sadly though, the problem seems a subtle issue in py2exe's mf.py and I'm struggling to find a work-around. The problem goes something like this: * The dir layout has foo/__init__.py, foo/foo.py and foo/problemchild.py * The first import in foo/__init__.py is: import foo.problemchild (which FWIW, does end up working in py3k, which explains that ImportError block) * py2exe is now looking for 'foo.foo.problemchild' given that import is in the 'foo' package. It (correctly) fails to find it. This is where it gets subtle - I think what is happening is that "foo.problemchild" is marked as not existing in the context of a 'foo' package and things go pear-shaped - at a later stage when looking for the real 'foo.problemchild' that context seems to have been ignored, so it doesn't bother to look - it already knows a 'foo.problemchild' doesn't exist. The same basic thing happens whether that "packages" option is used or not - it is just that when you specify it in "packages" the failure to locate it is fatal at build time, whereas if you don't specify it the failure is at runtime - but both cases seem to have the same root cause. I'm out of time for now to keep looking at this, and realistically will not get back to it for at least a few days. And-I-thought-it-would-turn-out-to-be-relatively-simple-ly, Mark |