wxpython + py2exe + innosetup

[Simon Dahlbacka]

Thomas Heller wrote:

> 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.

hmm, I added a bogus "import sys"

and removed zipfile="lib\common.zip" from the setup script, which seemed 
to generate strange results, py2exe generated lib\shared.zip and 
installing * from that directory _somehow_ produced lib\common.zip in 
the install dir (I have absolutely NO clue..), removing that line 
produces all files in the same directory, which SEEM to work after the 
little testing I have done, (except the no codecs found, which can be 
solved by adding encodings, OTOH, I cannot get Mark's solution (from 
py2exe wiki) to work with 'encodings', 'encodings.latin_1' to just get 
latin-1 encodings. I'm probably just too stupid to get it or something..

/Simon