wxpython + py2exe + innosetup

[Thomas Heller]

sdahlbac at abo.fi (Simon Dahlbacka) writes:

> simoninusa2001 at yahoo.co.uk (simo) wrote in message news:<30260531.0404272030.3fe52362 at posting.google.com>...
>> "Simon Dahlbacka" <sdahlbacSPAMSUX at abo.fi> wrote:
>> 
>> > I'm "exefying" an application that uses wxpython, some com to control excel
>> > and word and want to distribute this application.
>> > 
>> > after creating the executable with py2exe, it still works fine (at least on
>> > my development machine), however, if I create an installer package with
>> > innosetup, install it and try to run it, I get a busy cursor for a split
>> > second and then.. nothing. no errors no traceback no nothing.. viewing
>> > dependencies does not reveal anything strange, and running the installed
>> > program in a debugger just tells that the application has exited with code
>> > 0.

> another strange thing is that I tried to sprinkle "print I got here
> statements" all over the place, but didn't see any of those, even
> running from a console.

If you build it as windows program (not console), sys.stderr is
redirected to a logfile, and sys.stdout is redirected into the eternal
bitsink.  This is to prevent IO errors in your debug print statements,
or when tracebacks are printed.  The code which does this is in
py2exe/boot_common.py for your inspection and/or improvements.

You can also override this default behaviour by assigning your own
objects to sys.stdout and sys.stderr.

Unfortunately, this very code in py2exe 0.5.0 has a bug, which will be
triggered when the sys module is *not* imported in your main script (the
'sys' symbol is deleted too early in boot_common.py).

So, it could be that your program tries to report something, and then
'crashes' (meaning: fails to initialize).

I will release py2exe 0.5.1 later this week, which should have fixed
this and other bugs ;-).


What I usually do to find out why a program behaves strange, is to build
both a console *and* a windows version (with different names, say
app_c.exe and app.exe).  Then, you can (even on the target machine) run
the console version to see the debug prints, and after you have found
and fixed potential problems, run the windows version and delete the
console version again.  Or you simply don't create a shortcut for the
console version.

Hope that helps,

Thomas