collections.sys error

Issue #127 resolved
Adam H
created an issue

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

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/", line 18, in <module>
    from toolkit import toolkit_object
  File "/home/glue/anaconda/envs/fibersim/lib/python2.7/site-packages/pyface/", line 73, in <module>
  File "/home/glue/anaconda/envs/fibersim/lib/python2.7/site-packages/pyface/", line 38, in _init_toolkit
    be = import_toolkit(ETSConfig.toolkit)
  File "/home/glue/anaconda/envs/fibersim/lib/python2.7/site-packages/pyface/", 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 build:

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

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

My total 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/", base=base)])

Comments (22)

  1. Adam H reporter

    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?

  2. Thomas Kluyver

    That looks similar to the issue, but it's actually completely different. 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.

  3. Thomas Kluyver

    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 file, though.

  4. Thomas Kluyver

    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 import .... That is somehow getting found on Python 2, which it shouldn't be, and leading to this issue.

  5. Adam H reporter

    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.

  6. Thomas Kluyver

    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 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.

  7. Adam H reporter

    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.

  8. Thomas Kluyver

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

  9. Adam H reporter

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

  10. Adam H reporter

    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!

  11. Log in to comment