PyInstaller 2.0 problem with pyQt when using app.setWindowIcon(QtGui.QIcon(':/icons/icon.png'))

[Laurence]

Hi all,

When I add the following line to my PyQt script,

#     app.setWindowIcon(QtGui.QIcon(':/icons/icon.png'))

the PyInstaller single-dir and single-file bundles crash with no error reported. (Before bundling the app, everything works fine in the standard console). When I go back to PyInstaller 1.5.1 everything works fine. Just removing this line causes the bundle to be created without problem in 2.0. I also know that the QIcon is created properly so it really seems to be a problem with the app.setWindowIcon command via PyInstaller.

Somebody wrote here (http://stackoverflow.com/q/13379101/548598) that this was a bug in PyInstaller version 2. I found the same thing (i.e., it works in 1.5.1 but not in 2.0). Is this a known issue? If so, is there a workaround?

Laurence.

[Hartmut Goebel]

Am 14.05.2013 06:14, schrieb Laurence:

#     app.setWindowIcon(QtGui.QIcon(':/icons/icon.png'))

I Doubt, this is working at all. AFAIK ":/" ist not a valid path-begin on any system.

Also you should split this into two statements, using an intermediate assign. So you can test whether QIcon() *or* setWindowIcon is failing -- which might be a big difference for debugging.

the PyInstaller single-dir and single-file bundles crash with no error reported. (Before bundling the app, everything works fine in the standard console).

What do you mean wirh "standard console"? Are you running on Windows? Do you get error-output when starting the program from the console/shell?

--
Schönen Gruß
Hartmut Goebel
Dipl.-Informatiker (univ), CISSP, CSSLP

Goebel Consult
http://www.goebel-consult.de

Monatliche Kolumne: http://www.cissp-gefluester.de/2012-12-in-die-cloud-in-die-cloud-ab-wo-soll-die-sein
Blog: http://www.goebel-consult.de/blog/20050401

Goebel Consult ist Mitglied bei http://www.7-it.de/

[Hartmut Goebel]

Am 14.05.2013 12:52, schrieb Hartmut Goebel:

Am 14.05.2013 06:14, schrieb Laurence:

#     app.setWindowIcon(QtGui.QIcon(':/icons/icon.png'))

I forgot:

Of course the  filepath must be relative to the application directory and you must COLLECT the image-file in your .spec-file.

[Laurence Anthony]

Hi Harmut,

Thanks for replying.

On Tue, May 14, 2013 at 7:52 PM, Hartmut Goebel <h.go...@goebel-consult.de> wrote:

Am 14.05.2013 06:14, schrieb Laurence:

#     app.setWindowIcon(QtGui.QIcon(':/icons/icon.png'))

I Doubt, this is working at all. AFAIK ":/" ist not a valid path-begin on any system.

The :/ is being used because the icon is saved as a PyQt resource. :/ is the standard way to refer to PyQT resources. Remember, that I said from the outset that the program works without problem before I try to bundle it with PyInstaller. In other words, the regular script works fine. The path is *not* the issue.
 

Also you should split this into two statements, using an intermediate assign. So you can test whether QIcon() *or* setWindowIcon is failing -- which might be a big difference for debugging.

In my original post, I wrote " I also know that the QIcon is created properly". I did split the two statements and confirmed that QIcon is working correctly even after bundling with PyInstaller. The problem is with setWindowIcon. And, I repeat, the original program runs fine. The crash only happens after I bundle it with PyInstaller 2.0. (And with PyInstaller 1.5.1, it runs fine, too).

 

the PyInstaller single-dir and single-file bundles crash with no error reported. (Before bundling the app, everything works fine in the standard console).

What do you mean wirh "standard console"? Are you running on Windows? Do you get error-output when starting the program from the console/shell?

I should clarify what I mean. I am on Windows. I can run the original program (without errors) through my IDE (Eclipse), but for simplicity I can also run the program via the console. In short, the original program runs with no errors at all. It is fine.

After bundling the program, I add the console option to the one-file or one-dir build. This lets me see what happens when it runs. When I double click the executable, the bundled program crashes. The error report is "Python unexpectedly stopped working" (or something to that effect).

So, the problem seems to be setWindowIcon in PyInstaller 2.0

Laurence.

[Laurence Anthony]

On Tue, May 14, 2013 at 7:55 PM, Hartmut Goebel <h.go...@goebel-consult.de> wrote:

Am 14.05.2013 12:52, schrieb Hartmut Goebel:

Am 14.05.2013 06:14, schrieb Laurence:

#     app.setWindowIcon(QtGui.QIcon(':/icons/icon.png'))

I forgot:

Of course the  filepath must be relative to the application directory and you must COLLECT the image-file in your .spec-file.

Actually, this is not the case with PyQT resources. The icon effectively becomes embedded in a Python module. To access the icon, you just need to import the resource.py module and access the icon via :/... I can certainly try this though.

Laurence.

[Hartmut Goebel]

Hi Laurence,

And, I repeat, the original program runs fine. The crash only happens after I bundle it with PyInstaller 2.0. (And with PyInstaller 1.5.1, it runs fine, too).

So it comes down that you need to compare the result of the bundle made by PyInstaller 2.0 with th one made by PyInstaller 1.5.1. There ought to some difference in what is bundled. Did you already compare the content? http://www.pyinstaller.org/wiki/HowtoReportBugs#Beforesubmittingareport:Makesureeverythingispackaged should tell you how to do this.

(I do not understand this resource.py stuff, but this seams to be some QT magic.)

--
Schönen Gruß
Hartmut Goebel
Dipl.-Informatiker (univ), CISSP, CSSLP

Goebel Consult
http://www.goebel-consult.de

Monatliche Kolumne: http://www.cissp-gefluester.de/2011-09-kommerz-uber-recht-fdp-die-gefaellt-mir-partei
Blog: http://www.goebel-consult.de/blog/20060920

[Laurence Anthony]

Hi

 

So it comes down that you need to compare the result of the bundle made by PyInstaller 2.0 with th one made by PyInstaller 1.5.1. There ought to some difference in what is bundled. Did you already compare the content? http://www.pyinstaller.org/wiki/HowtoReportBugs#Beforesubmittingareport:Makesureeverythingispackaged should tell you how to do this.

(I do not understand this resource.py stuff, but this seams to be some QT magic.)

Definitely magic! :-)

I suspected that 1.5.1 and 2.0 are quite different and that I'd find all kinds of differences. Also, it's such a weird bug that I thought it was not a problem with PyInstaller at all, and I was just doing something wrong. Are there cases where a single PyQt command like this can fail when bundled with PyInstaller?

Laurence.

[Hartmut Goebel]

Am 14.05.2013 13:47, schrieb Laurence Anthony:

I suspected that 1.5.1 and 2.0 are quite different and that I'd find all kinds of differences.

Well, the *results* should be quite each other, since in the *result* both bundels sould work.

When comparing, mind to bundle in --onedir mode. This makes comparing easier.

[Laurence Anthony]

On Tue, May 14, 2013 at 8:57 PM, Hartmut Goebel <h.go...@goebel-consult.de> wrote:

Am 14.05.2013 13:47, schrieb Laurence Anthony:

I suspected that 1.5.1 and 2.0 are quite different and that I'd find all kinds of differences.

Well, the *results* should be quite each other, since in the *result* both bundels sould work.

When comparing, mind to bundle in --onedir mode. This makes comparing easier.

Hi again,

I compared the output from PyInstaller 1.5.1 and PyInstaller  2.0. This is what I found:

The bundle in 2.0 has some additional files than 1.5.1 and also some missing ones. Also, many filenames are the same but the sizes are very different. The most obvious missing ones are:
pywintypes27.dll
win32api.pyd

There are various extra files in the 2.0 version.

When I replaced the following file from the 2.0 version with the one from the 1.5.1 version, the 2.0 version suddenly worked!!
qt4_plugins->imageformats->qmng4.dll

So, qmng4.dll is the problem. Does that make any sense? In the 1.5.1 version it's 215 KB. In 2.0, it's 77 KB. But, as I wrote above, many of the files are of different size. Clearly, the 1.5.1 version of qmng4.dll is good.

Any suggestions why this is problematic in 2.0?

Laurence.

[Martin Zibricky]

Laurence Anthony píše v Út 14. 05. 2013 v 22:50 +0900:

> When I replaced the following file from the 2.0 version with the one
> from the 1.5.1 version, the 2.0 version suddenly worked!!
> qt4_plugins->imageformats->qmng4.dll
>
> So, qmng4.dll is the problem. Does that make any sense? In the 1.5.1
> version it's 215 KB. In 2.0, it's 77 KB. But, as I wrote above, many
> of the files are of different size. Clearly, the 1.5.1 version of
> qmng4.dll is good.
>
> Any suggestions why this is problematic in 2.0?
>
> Laurence.

It seems like you are hitting this issue:

http://www.pyinstaller.org/ticket/376

[Laurence Anthony]

Ah, very interesting.

I created a new test bundle today with UPX=True and the bundle ran without problem!? I then compared it to my test bundle from yesterday and that still died even though the folder contains exactly the same files with exactly the same sizes!

So, this compression bug that it not always causing problems. It's very difficult to pin down.

I then tried with UPX=False and, of course, that also ran.

So, at least we know that UPX may be responsible for odd bugs like this. It's good to know.

Laurence.

[Laurence]

Just a follow up. I made a completely new PyQT application today. When building with PyInstaller and UPX=True, I got the same bug as before (Python crashes when using  app.setWindowIcon). When I set UPX=False, the build completed and there were no errors with app.setWindowIcon. So, the conclusion is *do not use UPX=True when using PyQt*.

Laurence.

[Martin Zibricky]

Laurence píše v Út 21. 05. 2013 v 05:44 -0700:

> Just a follow up. I made a completely new PyQT application today. When
> building with PyInstaller and UPX=True, I got the same bug as before
> (Python crashes when using app.setWindowIcon). When I set UPX=False,
> the build completed and there were no errors with app.setWindowIcon.
> So, the conclusion is *do not use UPX=True when using PyQt*.
>
> Laurence.

Thanks for sharing your results.

[Hartmut Goebel]

Am 21.05.2013 15:45, schrieb Martin Zibricky:

Laurence píše v Út 21. 05. 2013 v 05:44 -0700:

So, the conclusion is *do not use UPX=True when using PyQt*.

Hmm, would it make sense to make the pyqt-hook *disable* UPX?

--
Schönen Gruß
Hartmut Goebel
Dipl.-Informatiker (univ), CISSP, CSSLP

Goebel Consult
http://www.goebel-consult.de

Monatliche Kolumne: http://www.cissp-gefluester.de/2012-02-bring-your-own-life-glosse
Blog: http://www.goebel-consult.de/blog/20050707

[Laurence]

On Tuesday, 21 May 2013 23:00:39 UTC+9, Hartmut Goebel wrote:

Am 21.05.2013 15:45, schrieb Martin Zibricky:

Laurence píše v Út 21. 05. 2013 v 05:44 -0700:

So, the conclusion is *do not use UPX=True when using PyQt*.

Hmm, would it make sense to make the pyqt-hook *disable* UPX?

As we know that UPX creates unstable pyqt (and I assume pyside) bundles, disabling it would make sense. However, having a hook that goes beyond its mission (to import modules) seems strange. I suggest simply documenting the problem in the section on UPX in the manual.

Also, in my view, I think the default setting for UPX should be *disabled* regardless of the application. In my view, the main problem of single file bundles is not their size but their slow startup time. Disabling UPX should speed up this process slightly. As we know UPX is also sometimes creating completely broken PyQT (Pyside?) applications, there is a chance that it is breaking other applications too. The console error reports are not helpful either. Python just crashes. Users of PyInstaller will just think that it doesn't work.

Laurence.

[Martin Zibricky]

Laurence píše v So 25. 05. 2013 v 03:30 -0700:

> Also, in my view, I think the default setting for UPX should be
> *disabled* regardless of the application. In my view, the main problem
> of single file bundles is not their size but their slow startup time.
> Disabling UPX should speed up this process slightly. As we know UPX is
> also sometimes creating completely broken PyQT (Pyside?) applications,
> there is a chance that it is breaking other applications too. The
> console error reports are not helpful either. Python just crashes.
> Users of PyInstaller will just think that it doesn't work.

So do you think it is safer and less error prone to have upx disabled by
default?

Does anyone else think upx should be disabled by default?

So then we should replace the option --noupx by --upx?

[Laurence Anthony]

On Mon, May 27, 2013 at 5:59 PM, Martin Zibricky <mzibr....@gmail.com> wrote:

Laurence píše v So 25. 05. 2013 v 03:30 -0700:

> Also, in my view, I think the default setting for UPX should be
> *disabled* regardless of the application. In my view, the main problem
> of single file bundles is not their size but their slow startup time.
> Disabling UPX should speed up this process slightly. As we know UPX is
> also sometimes creating completely broken PyQT (Pyside?) applications,
> there is a chance that it is breaking other applications too. The
> console error reports are not helpful either. Python just crashes.
> Users of PyInstaller will just think that it doesn't work.

So do you think it is safer and less error prone to have upx disabled by
default?

Yes. I think upx should be disabled by default.
 

Does anyone else think upx should be disabled by default?

So then we should replace the option --noupx by --upx?

My uses of PyInstaller are specifically for creating PyQt applications. So, I might be biased. The upx problem is a complete show stopper for PyQT apps. Also, upx doesn't even noticeably shrink the size of my apps. I have no use for it.

Laurence.

[Martin Zibricky]

Laurence píše v So 25. 05. 2013 v 03:30 -0700:

> As we know UPX is also sometimes creating completely broken PyQT
> (Pyside?) applications, there is a chance that it is breaking other
> applications too. The console error reports are not helpful either.
> Python just crashes. Users of PyInstaller will just think that it
> doesn't work.
>
> Laurence.

Do

[Laurence]

Sorry, what does "Do" mean here?

Laurence.

[Martin Zibricky]

Laurence píše v Út 28. 05. 2013 v 03:00 -0700:

> Do
>
>
> Sorry, what does "Do" mean here?
>
> Laurence.

Sorry, nothing. I was not clicking properly when responding to another
email.