search

marcelotduarte / cx_Freeze

cx_Freeze creates standalone executables from Python scripts, with the same performance, is cross-platform and should work on any platform that Python itself works on.
https://marcelotduarte.github.io/cx_Freeze/
Other
1.35k stars 218 forks source link

collections.sys error #127

Closed anthony-tuininga closed 7 years ago

anthony-tuininga commented 9 years ago

Originally reported by: Adam H (Bitbucket: hughesadam87, GitHub: Unknown)

I posted this to mailing list, but now think it's probably a bug after reading this fix:

69/python-340-can-not-import-collectionsabc

I froze a module and the freezing process went without error, but upon running to frozen program, I get this error:

 from pyface.image_resource import ImageResource
  File "/home/glue/anaconda/envs/fibersim/lib/python2.7/site-packages/pyface/image_resource.py", line 18, in <module>
    from toolkit import toolkit_object
  File "/home/glue/anaconda/envs/fibersim/lib/python2.7/site-packages/pyface/toolkit.py", line 73, in <module>
    _init_toolkit()
  File "/home/glue/anaconda/envs/fibersim/lib/python2.7/site-packages/pyface/toolkit.py", line 38, in _init_toolkit
    be = import_toolkit(ETSConfig.toolkit)
  File "/home/glue/anaconda/envs/fibersim/lib/python2.7/site-packages/pyface/toolkit.py", line 31, in import_toolkit
    __import__(be + 'init')
ImportError: No module named init

I figured this is a dynamic import issue (ie the pyface library is importing module dynamically), so I added pyface to my builde_exe_options which looks like this:

build_exe_options = {"packages": ["os","sys", "collections", "pyface" ]}

This leads to the following error upon running python setup.py build:

 File "/home/glue/anaconda/envs/fibersim/lib/python2.7/site-packages/cx_Freeze/dist.py", line 232, in run
    freezer.Freeze()
  File "/home/glue/anaconda/envs/fibersim/lib/python2.7/site-packages/cx_Freeze/freezer.py", line 626, in Freeze
    self.compress, self.copyDependentFiles)
  File "/home/glue/anaconda/envs/fibersim/lib/python2.7/site-packages/cx_Freeze/freezer.py", line 526, in _WriteModules
    module.Create(finder)
  File "/home/glue/anaconda/envs/fibersim/lib/python2.7/site-packages/cx_Freeze/freezer.py", line 762, in Create
    module.file, module.name)
cx_Freeze.freezer.ConfigError: no file named sys (for module collections.sys)

I naively added a line for "collections.sys" to mimic the "collections.abc" fix, but it made no difference.

My total setup.py script looks as follows:


import sys
from cx_Freeze import setup, Executable

# Dependencies are automatically detected, but it might need fine tuning.
build_exe_options = {"packages": ["os","sys", "collections", "pyface" ]}#, "excludes": ["tkinter"]}

# GUI applications require a different base on Windows (the default is for a
# console application).
base = None
if sys.platform == "win32":
    base = "Win32GUI"

setup(  name = "pamebinary",
        version = "0.1",
        description = "My GUI application!",
        options = {"build_exe": build_exe_options},
        executables = [Executable("../pame/pamemain.py", base=base)])
anthony-tuininga commented 8 years ago

Original comment by Anthony Tuininga (Bitbucket: anthony_tuininga, GitHub: Unknown):

Corrected by commit https://bitbucket.org/anthony_tuininga/cx_freeze/commits/c580734d42274df3080679cfb637b4dd475f2fa0

cx_Freeze was attempting a relative import of a builtin module and incorrectly considering it an extension found within a package.

anthony-tuininga commented 9 years ago

Original comment by Adam H (Bitbucket: hughesadam87, GitHub: Unknown):

I think I've uncovered another bug involved with PyQt4. I put a new stack overflow thread up if you are interested in checking it out sometime.

http://stackoverflow.com/questions/28101609/cx-freeze-and-pyqt4

If you have a chance to glance at some point, it might be an obvious issue to you. I have a feeling most stackoverflow users will ignore it. Thanks for all of your help today.

anthony-tuininga commented 9 years ago

Original comment by Adam H (Bitbucket: hughesadam87, GitHub: Unknown):

Ok, awesome thanks!

I think I'm getting close.

anthony-tuininga commented 9 years ago

Original comment by Adam H (Bitbucket: hughesadam87, GitHub: Unknown):

That certainly does seem to fix the build process! Upon running though I get:

ImportError: Unable to import the image backend for the qt4 toolkit (reason: ['ImportError: No module named qt4.image\n']).

Seems like I need to add qt to packages, but will investigate. Thanks!

anthony-tuininga commented 9 years ago

Original comment by Thomas Kluyver (Bitbucket: takluyver, GitHub: takluyver):

All of the options includes, packages and excludes work by importable package names, so PyQt is PyQt4.

anthony-tuininga commented 9 years ago

Original comment by Thomas Kluyver (Bitbucket: takluyver, GitHub: takluyver):

collections.abc. Probably either will work, but abc stops the problem a bit sooner, so it might avoid another instance of a similar issue.

anthony-tuininga commented 9 years ago

Original comment by Adam H (Bitbucket: hughesadam87, GitHub: Unknown):

Wait, collections.abc or collections.sys? PS, to include "qt" in build_exe_options, is the abbreviation "qt", "qt4", "pyqt" etc..? Do you know which offhand?

anthony-tuininga commented 9 years ago

Original comment by Thomas Kluyver (Bitbucket: takluyver, GitHub: takluyver):

Don't worry, it wasn't obvious. ;-) I just meant that it's an easy change to make once you know what it is.

anthony-tuininga commented 9 years ago

Original comment by Adam H (Bitbucket: hughesadam87, GitHub: Unknown):

Awesome, thanks! Probably obvious to all but a total noob.

anthony-tuininga commented 9 years ago

Original comment by Thomas Kluyver (Bitbucket: takluyver, GitHub: takluyver):

Oh, I'd forgotten to think about a quick and dirty workaround to get things moving. It's easy, just add 'excludes': ['collections.abc'] to build_exe_options in your script, and you should get past that.

anthony-tuininga commented 9 years ago

Original comment by Adam H (Bitbucket: hughesadam87, GitHub: Unknown):

I'm really eager to see if this fix will let cx_freeze complete the process for freezing my GUI, or if it will just lead to the next in a possibly long line of issues. If you find any quick and dirty workarounds (even going into a module and changing a lines of code), let me know so I can test if my GUI freeze goes to completion. Also let me know if there's any other way I can assist.

anthony-tuininga commented 9 years ago

Original comment by Thomas Kluyver (Bitbucket: takluyver, GitHub: takluyver):

I shoved some ugly debugging code into ModuleFinder (like if name == 'collections.sys': raise DBGExc) and worked backwards until I reached a real module.

Now, I've been thinking of trying to pull out our finder.py module and replace it with modulegraph (see issue #123). So the question is whether it's worth trying to fix ModuleFinder, or just work on getting rid of it.

But first, lunch.

anthony-tuininga commented 9 years ago

Original comment by Adam H (Bitbucket: hughesadam87, GitHub: Unknown):

I don't know how you found that so fast, but thank you! Is this in only one module, or are several modules using this import name? Let me know if I can help further.

anthony-tuininga commented 9 years ago

Original comment by Thomas Kluyver (Bitbucket: takluyver, GitHub: takluyver):

On investigation, it's jsonschema (which pyface loads via IPython) that actually causes the bug. Specifically, in jsonschema.compat, it has the Python 3 import from collections.abc import .... That is somehow getting found on Python 2, which it shouldn't be, and leading to this issue.

anthony-tuininga commented 9 years ago

Original comment by Thomas Kluyver (Bitbucket: takluyver, GitHub: takluyver):

Bingo, that does it.

anthony-tuininga commented 9 years ago

Original comment by Adam H (Bitbucket: hughesadam87, GitHub: Unknown):

What if you add "pyface" to the packages?

anthony-tuininga commented 9 years ago

Original comment by Adam H (Bitbucket: hughesadam87, GitHub: Unknown):

Can you add "pyface" to the packages and just see if that reproduces it?

anthony-tuininga commented 9 years ago

Original comment by Thomas Kluyver (Bitbucket: takluyver, GitHub: takluyver):

Well, that's it - there is no collections.sys. Somehow the import-tracing code is mistakenly determining that something is trying to load collections.sys, so it looks for that module to copy in. I can't reproduce it by adding 'collections' to packages in a simple setup.py file, though.

anthony-tuininga commented 9 years ago

Original comment by Adam H (Bitbucket: hughesadam87, GitHub: Unknown):

Ok, thanks. I'll try to find an example. What is collections.sys as opposed to sys?

anthony-tuininga commented 9 years ago

Original comment by Thomas Kluyver (Bitbucket: takluyver, GitHub: takluyver):

That looks similar to the collections.abc issue, but it's actually completely different. collections.abc is a module that exists, at least in Python 3.4, and the frozen application was failing to find it at runtime. collections.sys doesn't exist, and the failure is at build time. You're also using Python 2.7, where collections is a module, not a package. Can you try to find a minimal example that reproduces the problem? I'll investigate too.

anthony-tuininga commented 9 years ago

Original comment by Adam H (Bitbucket: hughesadam87, GitHub: Unknown):

I'm kind of new to bitbucket and don't quite know the workflow, but does everyone working on cx_freeze see this issue, or do I have to share it with others specifically?