0

I dealt with this issue several posts back where I somehow accidentally "solved" the problem, but predictably it has resurfaced. I need to make my Python script executable just by clicking on it. I have already read the information posted in How to execute Python scripts in Windows?; but I am having an issue wherein scriptA that the user executes with the shortcut calls scriptB which is then unable to import user installed modules. This program works perfectly fine when I execute it like so:

python scriptA.py

But, the combination of calling scriptA by clicking on it and having it call scriptB gives scriptB import errors that do not occur otherwise. Thinking this was a path issue, I tried adding as many possible paths to PATH and PYTHONPATH as they could possibly need, which just gives a different but related import error.

In scriptA I have

from Tkinter import *
from subprocess import call
import numpy

# some code 
call(["python", "levMap12.py", inputFilePath, outputFilePath, LVscalingFactor, corrFilePath, corrScalingFactor])

And in scriptB I have

import math
import Levenshtein as LV
import csv
import openpyxl
import sys
import pickle

# some code 

File paths:

PATH
C:Python27;C:Python27\Scripts;C:Python27\Lib;C:Python26;C:\Python26\Scripts;C:\Python26\Lib;C:\python-Levenshtein-0.12.0\Levenshtein;C:\Python26\Lib;C:\python-Levenshtein-0.12.0;C:\Program Files\7-Zip\

PYTHONPATH
C:\python-Levenshtein-0.12.0\Levenshtein;C:\python-Levenshtein-0.12.0

Full trackback:

Traceback (most recent call last):
  File "levMap12.py", line 3, in <module>
    import Levenshtein as LV
  File "C:\python-Levenshtein-0.12.0\Levenshtein\__init__.py", line 1, in <module>
    from Levenshtein import _levenshtein
ImportError: cannot import name _levenshtein

This error occurs when I simply double click on the scriptA.py file. However, when I try to execute the file by choosing open with python.exe, I get another error

python: can't open file 'levMap12.py': [Errno 2] No such file or directory

I have enabled the setting to use python.exe for all .py files and added .PY to the PATHTEXT system variable

Also, if it is of any relevance, I am using Windows 8 and Python 2.7

Community
  • 1
  • 1
Luca
  • 515
  • 5
  • 17
  • 1
    If "levMap12.py" is to be found relative to the current script, you should do that explicitly via `__file__`. Don't rely on the current directory to find program files. Double clicking on a script just happens to run it with the current directory set to the script directory, and "open with" just happens to run it with the current directory set to the Windows "System32" directory. – Eryk Sun Jul 19 '16 at 20:42
  • 1
    The OS `PATH` environment variable is unrelated to this problem. That's for finding files to execute, but "python.exe" will always be found since Windows implicitly searches the application directory first, which is not the same as the current directory. – Eryk Sun Jul 19 '16 at 20:46
  • I don't recommend permanently setting a directory in `PYTHONPATH` unless the modules and packages in that directory are written to work in both Python 2 and 3. Instead in the `subprocess.call` you can modify the environment passed to the child process. For example: `environ = os.environ.copy();` `environ['PYTHONPATH'] = r'C:\python-Levenshtein-0.12.0\Levenshtein;C:\python-Levenshtein-0.12.0';` `subprocess.call(["python", path_to_levmap12, inputFilePath, outputFilePath, LVscalingFactor, corrFilePath, corrScalingFactor], env=environ)`. – Eryk Sun Jul 19 '16 at 20:53
  • I deleted my PYTHONPATH and tried what you recommended getting the same result. If I deleted my PYTHONPATH and then did not apply your suggestion I got a traceback ImportError: No module named Levenshtein – Luca Jul 19 '16 at 21:17
  • So, if I am understanding this correctly, the problem likely stems from the proper environment variables not being carried over from the parent process to the child process. Is this correct? – Luca Jul 19 '16 at 21:19
  • Then why would the program not raise this error when I run it the normal way of \>python scriptA.py ? – Luca Jul 19 '16 at 21:28
  • You have `from Levenshtein import _levenshtein`. Is there a `_levenshtein` module or package there or isn't there? – Eryk Sun Jul 19 '16 at 21:34
  • My program imports the module called Levenshtein not _levenshtein. In past programs, all I had to do was import Levenshtein. But for whatever reason, the module cannot seem to recognize one of its own source files _levenshtein.c, _levenshtein.h or whatever. – Luca Jul 19 '16 at 21:38
  • As far as I am aware, there is no module named _levenshtien and even if there were, it was never necessary to import it or include it in PATH or PYTHONPATH. So, clearly something is different about the way these scripts are interacting. – Luca Jul 19 '16 at 21:40
  • "_levenshtein.c" is a C source file, which has to be compiled to create `_levenshtein.pyd`. Did you actually install this package via pip with a wheel or from source with setup.py, or are you trying to use the unzipped source distribution directly? There's no way that's going to work if it requires an extension module to be built. – Eryk Sun Jul 19 '16 at 21:41
  • I used pip to install it. I tested it. It imported in a python shell and worked. It just does not import correctly in this situation. – Luca Jul 19 '16 at 21:42
  • 1
    Then why are you adding `C:\python-Levenshtein-0.12.0` to `PYTHONPATH`? It should be installed in Python's "Lib\site-packages" directory. Maybe you installed it to the wrong version of Python. – Eryk Sun Jul 19 '16 at 21:44
  • Okay, I'll try that out. Thanks. – Luca Jul 19 '16 at 21:45
  • I think that was the problem. When I executed scriptA.py by clicking, it was using a version of python that did not have Levenshtien installed on it. Thank you. If you want to put that as an answer, I will accept it. – Luca Jul 19 '16 at 21:54
  • I'll add an answer in a bit. I should also add more detail about how Windows file associations are defined. Even though it's heavily upvoted, the linked answer is incomplete. For example, `ftype` and `assoc` only show the basic `HKLM` definitions, not the various other keys in `[HKCU|HKLM]\Software\Classes` that affect file associations and definitely not the *user's choice* in Explorer. Plus telling people to set anything in the `HKCR` registry view is wrong. It's really only intended for reading `[HKCU|HKLM]\Software\Classes`. – Eryk Sun Jul 19 '16 at 23:21

0 Answers0