wxpython + py2exe + innosetup

[Simon Dahlbacka]

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.

...where do I go from here, I'm running out of ideas.. ?

/Simon

[simo]

Re: wxpython + py2exe + innosetup

"Simon Dahlbacka" <sdahlbacSPAMSU X@abo.fi> wrote:
[color=blue]
> 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.[/color]

Does the program rely on any paths to files - i.e. does it open your
Excel/Word file from the current directory?

This is the only problem I've ever found with Inno - it's an FAQ too,
there's an option to set the "Run From" property in the shortcuts. The
sympton is that it won't work from the shortcut in Start/Desktop but
will work from the program directory.

What about permissions - if you installed it as non-Admin and it needs
to write something Admin-only.....

ISTool can make the InnoSetup options a bit easier to deal with -
maybe you're accepting a default that needs to be changed?

Some useful tips here:

http://starship.python.net/crew/theller/moin.cgi/BetterCompression

[Simon Dahlbacka]

Re: wxpython + py2exe + innosetup

simoninusa2001@ yahoo.co.uk (simo) wrote in message news:<30260531. 0404272030.3fe5 2362@posting.go ogle.com>...[color=blue]
> "Simon Dahlbacka" <sdahlbacSPAMSU X@abo.fi> wrote:
>[color=green]
> > 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.[/color]
>
> Does the program rely on any paths to files - i.e. does it open your
> Excel/Word file from the current directory?[/color]

it _should_ not, I had a problem with this earlier regarding icons,
but switched over to resourcepackage now. And both Excel and Word
doesn't do any filehandling until I explicitely "hit the button"
[color=blue]
> This is the only problem I've ever found with Inno - it's an FAQ too,
> there's an option to set the "Run From" property in the shortcuts. The
> sympton is that it won't work from the shortcut in Start/Desktop but
> will work from the program directory.
>
> What about permissions - if you installed it as non-Admin and it needs
> to write something Admin-only.....[/color]

...hmm, I'm just doing a default install, there is however registry
settings involved, but since I've installed it being admin and running
it being admin, I doubt this is the problem.
[color=blue]
> ISTool can make the InnoSetup options a bit easier to deal with -
> maybe you're accepting a default that needs to be changed?[/color]

hmm, never heard of that, I have to check it out later..

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.


/Simon

[Thomas Heller]

Re: wxpython + py2exe + innosetup

sdahlbac@abo.fi (Simon Dahlbacka) writes:
[color=blue]
> simoninusa2001@ yahoo.co.uk (simo) wrote in message news:<30260531. 0404272030.3fe5 2362@posting.go ogle.com>...[color=green]
>> "Simon Dahlbacka" <sdahlbacSPAMSU X@abo.fi> wrote:
>>[color=darkred]
>> > 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.[/color][/color][/color]
[color=blue]
> 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.[/color]

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

[Simon Dahlbacka]

Re: wxpython + py2exe + innosetup

Thomas Heller wrote:
[color=blue]
> sdahlbac@abo.fi (Simon Dahlbacka) writes:
>
>[color=green]
>>simoninusa200 1@yahoo.co.uk (simo) wrote in message news:<30260531. 0404272030.3fe5 2362@posting.go ogle.com>...
>>[color=darkred]
>>>"Simon Dahlbacka" <sdahlbacSPAMSU X@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
>>>>dependencie s does not reveal anything strange, and running the installed
>>>>program in a debugger just tells that the application has exited with code
>>>>0.[/color][/color]
>
>[color=green]
>>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.[/color]
>
>
> 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.[/color]

hmm, I added a bogus "import sys"

and removed zipfile="lib\co mmon.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.lati n_1' to just get
latin-1 encodings. I'm probably just too stupid to get it or something..

/Simon