PyQt4 Mac deployment

16 views
Skip to first unread message

Hans-Peter Jansen

unread,
Jun 26, 2009, 1:19:17 PM6/26/09
to PyIns...@googlegroups.com
Dear Giovanni et.al.,

first of all - awesome work!

I just fiddled for half an hour with PyInstaller, and got something working
on the Mac - even as single file, and that's me being a Mac greenhorn...

Now a few issues still stand: when I run my script.pyw by double click, all
is well (more or less, I really don't like the "Python Launcher"
redirection at all), but after a few clicks into it, no terminal is opened
anymore. Unlike executed as a one file image - then a terminal window is
opened all the time, echoing the command: /path/to/Image.app; exit

It would be nice to get the -w option of Makespec.py going for the Mac, too.

While at it, it would be great to have the --icon option working for the
Mac, too (hopefully accepting PNG files).

Other then these, it's a real pleasure to work with PyInstaller. I was able
to include the translation files with minimum fuzz - but again, more of a
nitpick, you noted the inclusion of arbitrary files in the manuals TOC
section, but added them to the a.binaries set, even if there seem to exist
a dedicated set for it: a.datas. Not that it seems to make a difference ;-)

Thanks & a nice weekend,
Pete

Hans-Peter Jansen

unread,
Jun 27, 2009, 10:32:19 AM6/27/09
to PyIns...@googlegroups.com
Am Freitag, 26. Juni 2009 schrieb Hans-Peter Jansen:
> Dear Giovanni et.al.,
>
> first of all - awesome work!
>
> I just fiddled for half an hour with PyInstaller, and got something
> working on the Mac - even as single file, and that's me being a Mac
> greenhorn...
>
> Now a few issues still stand: when I run my script.pyw by double click,
> all is well (more or less, I really don't like the "Python Launcher"
> redirection at all), but after a few clicks into it, no terminal is
> opened anymore. Unlike executed as a one file image - then a terminal
> window is opened all the time, echoing the command: /path/to/Image.app;
> exit
>
> It would be nice to get the -w option of Makespec.py going for the Mac,
> too.

Okay, after more experimenting and code exploration, I found out, that you
do honor the -w option on the Mac in some way, as noted in the ChangeLog.
Unfortunately, no matter how I build my project, (one file or one dir,
console=0|1), the resulting exe / dir is working fine, but opens the
dreaded terminal window. Strangely enough, if I run it from a console
(local or remote), then no extra terminal window is opened _nor_ is
anything printed in that console.

It looks like some finder redirection mechanisms generates some console
output and throws that into a terminal window, but I don't understand this
at all. Anybody from the audience?

In order to get my app displaying an icon in finder, I've learned to create
an .app folder, created Contents/Info.plist, added an icon in .icns Format
and an empty.lproj to Contents/Resources and my app image/files into
Contents/MacOS.

While the app appears as the icon, unfortunately, it doesn't run at all.
Double clicking on it let the icon jump for some seconds, and thats it.
No application :-(, similar to:
$ open -a My.app
[blink, blink]
$

Needless to say, starting my app via console inside the .app/Contents/MacOS
folder does work, as well as double clicking it (with the extra console
window opened).

Looks like the app needs some build option added to be created as bundle
correctly.

For the sake of completeness, I should have mentioned the versions in use:
Mac OS-X 10.4.11 (PowerPC)
Python 2.6.2
Qt 4.5.1
PyQt 4.5
PyInstaller (current SVN)

Any hints/ideas on how to get rid to this issue are greatly appreciated.

Pete

Giovanni Bajo

unread,
Jun 30, 2009, 8:23:48 AM6/30/09
to PyIns...@googlegroups.com

Hi Pete,

In [685], I've just committed preliminar supporto for building a bundle
(.app) on Mac OSX. Right now, only the core functionality has been
commmitted: it has yet to be integrated within Makespec.py.

To test it, add this at the bottom of your .spec file:

import sys
if sys.platform.startswith("darwin"):
app = BUNDLE(exe,
appname=name,
version=version)

It should correctly supports icons, and work in both one-file and
one-dir mode.

What I plan to do is to:

1) Make it so BUNDLE() is automatically a nop on platforms != darwin (so
to not be forced to put that "if" statement within the spec file)

2) Modify the templates in Makespec.py so that it adds a BUNDLE()
command whenever -w/--windowed is specified.

Patches are of course welcome :)
--
Giovanni Bajo
Develer S.r.l.
http://www.develer.com

Hans-Peter Jansen

unread,
Jun 30, 2009, 12:01:40 PM6/30/09
to PyIns...@googlegroups.com
Hi Giovanni,

Meanwhile I was able to solve this issue.

If executed as a bundle, for some unknown reason, the app gets started with
an -psn_0_2490369 option, but to spot this, I had to discover Console.app
first. Oh well..

> Hi Pete,
>
> In [685], I've just committed preliminar supporto for building a bundle
> (.app) on Mac OSX. Right now, only the core functionality has been
> commmitted: it has yet to be integrated within Makespec.py.

Sounds cool.

> To test it, add this at the bottom of your .spec file:
>
> import sys
> if sys.platform.startswith("darwin"):
> app = BUNDLE(exe,
> appname=name,
> version=version)
>
> It should correctly supports icons, and work in both one-file and
> one-dir mode.

That gets me started, thanks.

> What I plan to do is to:
>
> 1) Make it so BUNDLE() is automatically a nop on platforms != darwin (so
> to not be forced to put that "if" statement within the spec file)
>
> 2) Modify the templates in Makespec.py so that it adds a BUNDLE()
> command whenever -w/--windowed is specified.
>
> Patches are of course welcome :)

Okay. Will test this soon.

ATM, I harvesting some crashes in the shutdown sequence most often than not:

Exception: EXC_BAD_ACCESS (0x0001)
Code[0]: 0x00000103
Code[1]: 0x00000001


Thread 0 Crashed:
0 QtCore 0x014d5c88 QHash<QRegExpEngineKey,
QCache<QRegExpEngineKey, QRegExpEngine>::Node
>::duplicateNode(QHashData::Node*, void*) + 40
1 QtCore 0x014c88c4
QRegExpEngine::~QRegExpEngine [not-in-charge]() + 52
2 QtCore 0x014c9018 __tcf_0 + 72
3 QtCore 0x014790e4 cxa_atexit_wrapper + 172
4 libSystem.B.dylib 0x9001495c __cxa_finalize + 232
5 libSystem.B.dylib 0x90014844 exit + 36
6 Python 0x010ef088 handle_system_exit + 364
(pythonrun.c:1118)
7 Python 0x010ef0d4 PyErr_PrintEx + 56
(pythonrun.c:1128)
8 Python 0x010f03b0 PyRun_SimpleStringFlags +
100 (pythonrun.c:1035)
9 ...-.creport.CReport 0x000051f0 runScripts + 272
(launch.c:1044)
10 ...-.creport.CReport 0x000032bc main + 556 (main.c:147)
11 ...-.creport.CReport 0x0000279c _start + 760
12 ...-.creport.CReport 0x000024a0 start + 48

but I suspect, that the hardware is probably flaky..

Thanks again,
Pete

Reply all
Reply to author
Forward
0 new messages