PyInstaller fails to load Werkzeug modules

[pyinstaller-tickets-migration]

Original date: 2012/09/04
Original reporter: torsten DOT landschoff AND dynamore DOT de

I am trying to deploy an application that uses Werkzeug but I am unable to get PyInstaller to include the werkzeug.* modules. Look at this example:

#!py
from werkzeug.exceptions import InternalServerError
print "Hello World!"

Obviously this works fine when called directly from Python. Using pyinstaller on test.py without any options gives an executable which acts like this:

torsten@sharokan:~/pyinstaller-test$ ~/workspace/pyinstaller-2.0/pyinstaller.py test.py
torsten@sharokan:~/pyinstaller-test$ ./dist/test/test 
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/home/torsten/workspace/pyinstaller-2.0/PyInstaller/loader/iu.py", line 409, in importHook
    raise ImportError("No module named %s" % fqname)
ImportError: No module named werkzeug.exceptions

I created a hook to make PyInstaller include the werkzeug submodules and placed it into the directory hookspath. I enabled that hook by modifying the generated test.spec to include

#!py
a = Analysis(['test.py'],
             pathex=['/home/torsten/pyinstaller-test'],
             hiddenimports=[],
             hookspath="hookspath")

But I noticed that this does not make a difference for the build result: The file logdict2.7.3.final.0-2.log is unchanged. In fact, the original version also contains the werkzeug.exceptions module (verified with ArchiveViewer.py).

Why this module can not be loaded is beyond me. I enabled the debug output of iu.py and will attach that file. Perhaps somebody with more insight into PyInstaller internals can go and fix the loader.

The only workaround I found was to replace the init.py in the werkzeug package to remove the lazy load feature by commenting out the last lines so that new_module is not written into sys.modules["werkzeug"].

[pyinstaller-tickets-migration]

Original date: 2012/09/05
Original reporter: Doug Johnston

Agreed. I've run into this same issue. I'm not familiar enough with pyinstaller to know how the lazy loading affects it, but it would definitely be nice if this was handled.

Thanks for posting a workaround though.

[htgoebel]

@Bluehorn: Is it you who opened this issue originally at the old trac-instance? If so: Is this still an issue with PyInstaller 3.1.1?

[Bluehorn]

@htgoebel: Yep, that's me. I will check if this works in PyInstaller 3.1.1. We are still at our fork from PyInstaller trunk from years ago because we have a lot of local fixes. Not sure if we will upgrade before our switch to CPython 3 which is likely to take a few more years...

[Bluehorn]

Just checked with PyInstaller 3.1.1 and the resulting binary worked just fine.

[htgoebel]

It's time to finally fix or close this issue.

[Bluehorn]

It's time to finally fix or close this issue.

AFAICT this has been fixed long ago. I can't close the ticket though as I am not listed as the creator on github: The ticket was ported over from trac.
I am all for closing this!