Incorrect paths in installed cxfreeze scripts...

Issue #11 resolved
David Lotton
created an issue

When attempting to execute the cxfreeze script I kept getting 'The system cannot find the path specified.'

After many hours of googling and bashing my head on the table I looked at the cxfreeze scripts that were installed. The paths in these scripts did not match the path to my python installation.

The base path to the python installation on my system is 'c:\python27'. This is where 'python.exe', 'scrpits\', 'libs\', etc... live. For some reason the installed cxfreeze scripts were referring to base paths of 'c:\python\32-bit\2.7' and 'c:\python\64-bit\2.7'.

I'm not sure where those paths came from. When I installed python I just did a straight install without any modifications to the install path during install.

When I installed cx_Freeze there was some mention of using the Python found in the registry. I searched the registry and any references to python were at the 'C:\python27' path, there were no registry keys that had paths that looked like the paths shown in the cx_Freeze scripts.

[edit] I modified the base path in all of the installed scripts in the 'c:\python27\Scripts' directory and that seemed to fix the problem.

Comments (13)

  1. Anthony Tuininga repo owner

    Actually, those paths are the ones I have on my system as the default (c:\python27) would not work for both 32-bit and 64-bit installations. I'm not sure what the best solution to this problem is but I'll look into it.

  2. David Lotton reporter

    At the very least it may be worth a mention in the docs since this seems to be the default python install location on a '64-bit only' install, but hopefully you can come up with a more automated way to address the issue.

    Thanks for taking a look.

  3. Anthony Tuininga repo owner

    Yes, the default installation location does not match the one I use. I could probably get away with forcing the "default" but instead I wrote a post-install script that fixes the paths as needed and creates the batch files. Formerly that was done during the build process. I am hoping to make a new release shortly which will include this. In the meantime you already have a working solution. Thanks for taking the time to point it out.

  4. Jason Tan

    Changes made in c59dc97 work for default installations of Python in Windows where python.exe resides in the root path (e.g. C:\Python27\python.exe), but not for virtualenv environments where the python executable is inside the Scripts subdirectory.

  5. Walker Inman

    Is this supposed to be fixed in 4.3.1? I'm getting an ImportError with one of my modules (that is there in the .zip file) and the traceback is saying that

    ... (a long traceback with 4 lines in ...
    File "C:\Python\32-bit\3.3\lib\importlib\", line 1525 in _find_and_load_unlocked
    File "C:\Users\me\software\myproject\modulea\" line 13, in <module>
    from myproject.modulea import submoduleb
    ImportError: cannot import name submoduleb

    There is no C:\Python directory on my computer.. I'm not sure if this is related to my frozen program not working... Also, if this is supposed to be included in 4.3.1 ( I'm not sure it is completely fixed.

  6. Walker Inman

    @Thomas Kluyver I know this issue is not the same as my primary issue, but it seems quite strange that my traceback references in a directory that does not exist on my comptuer..

    there must still be other places in cx_freeze where a base path of C:\Python\ is referenced regardless of whether or not it exists

  7. Thomas Kluyver

    Ah, I think I know what that might be. importlib._bootstrap is a new thing in Python 3.3 - the import system is now written in Python, not in C. But that creates a difficulty, because what do you use to import the import system? So a copy of importlib/ is effectively frozen into the Python interpreter itself. That path must be from the machine that was used to make the Windows Python builds.

  8. Log in to comment