"No module named os" when running Python Script in ArcGIS

[RobertWall]

I am writing this to possibly help others who may come across this message when running in the ArcGIS Geoprocessor. Here is a test script to illustrate the issue related to importing the OS Module into a script running in ArcGIS (i.e., the script runs with no problem in PythonWin):

print "\n- - - - - - - - - - - - - - - - - - S T A R T - - - - - - - - - - - - - - - - - - - -\n"

# Import modules and create the geoprocessor object (gp)

import sys, os, arcgisscripting as ARC

gp = ARC.create(9.3)

print "\n- - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - -\n"


PythonWIN Results:

- - - - - - - - - - - - - - - - - - S T A R T - - - - - - - - - - - - - - - - - - - -


- - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - -

>>>

Geoprocessor Results:

Start Time: Wed Sep 15 16:21:21 2010
Running script testOS...
<type 'exceptions.ImportError'>: No module named os
Failed to execute (testOS).
End Time: Wed Sep 15 16:21:22 2010 (Elapsed Time: 1.00 seconds)

SOLUTION: The ntpath.pyc module, necessary for importing the os module, is not in the C:\Program Files\ArcGIS\bin path. To resolve this, if it happens to you, set the PYTHONPATH Environment variable to include the path to the same directory where PythonWin finds the ntuser.pyc module. You can determine this easily by going to the Interactive Window in PythonWin or IDLE and typing: import os; os.path. It will typically be in the following directory C:\Python25\Lib or something like that. Include that path as a value in your PYTHONPATH Environment variable (separate paths with semicolons) and see if this test script will run as a Script Tool in the ArcGIS Toolbox. It should work. It did for me.

Apparently, when running in PythonWin, the loader searches in the same directory where the python.exe is found and doesn't use (need) PYTHONPATH to resolve the reference. When running under the python.exe in the C:\Program Files\ArcGIS\bin it does need PYTHONPATH to resolve the reference. On the other hand, when running in PythonWin, the loader does use the PYTHONPATH Environment variable to resolve the arcgisscripting reference.

Robert

[KimOllivier]

You must have a strange installation. The os module works for me without any hacking.

My pythonpath is set to C:\arcgis\bin (which I am not all that comfortable with) but I don't seem to need to set it to c:\python25\lib as well to work as a script.

The os module behaves at 10 for me as well.

[IanKramer]

I had the same problem with ArcGIS 10 SP1 (Win 7 64-bit).  I'm also think that installing PythonWin messes something up with ArcGIS Desktop.  I just had to create a environmental variable called "PYTHONPATH" and set it to "C:\Python26\ArcGIS10.0\Lib".  That fixed the issue.  Thanks Robert for the solution!

[KimOllivier]

The strange location of Python doubly installed by ArcGIS must have something to do with it. I don't like having a second copy of Python that Esri installs, sure to end in tears! I delete the copy and leave or put Python in the conventional location. (I keep the Desktop10.pth file and the numpy folder from site-packages that Esri adds, uninstall Python and reinstall manually in the conventional location. Then I copy back the two saved settings.)

C:/Python25 or C:/Python26 is the Proper Place for Python IMHO. It is then very predictable for other installed packages and editors. Everything then works properly, especially Python Help files. There is no DOT in the path so that dirname and basename are easier to parse. Fixing that would be my wish for a service pack, but I doubt if it will happen because this was raised during the Beta testing. I didn't see any valid reason given to do it that way and have had nothing but trouble since with any installation configured like that if you are going to extend Python or do development.

[NiklasNorrthon]

I too raised the issue during beta testing. The double installation really is painful, but I too have learned to live with it. Maybe something for ideas.arcgis.com...

[GavinMcDade]

I had an issue with this...  As it turned out, during the installation, Python somehow defaulted to being installed on my E: drive (an external I had at the time), but went unnoticed?!  That drive died a while back, but I didn't realize that Python was pointing there.  I've been having issues with certain tools in ArcToolbox, but didn't put the two together until finally getting around to troubleshooting it now and seeing the post above.  Double-checking my IDLE shortcut path, I saw the reference to E:.  Having recovered my deceased drive's contents which were restored to another volume, I simply copied the Python25 directory to C: (where it should've been anyway), added the path to my environmental variable, rebooted, and all is well. 

Thanks for the above info!

[ChristopherEbright]

Thanks Robert! I have been beating my head against the wall on this one and your suggestion worked.

[zhengniu]

Hi, all

Still have no idea how to make import os work

is there any pro. can give clear instruction step by step, please?

By following Robert's instruction, I can find the os.path. Question is: how to include path as a value in PYTHONPATH Environment variable (separate paths with semicolons) ????

[KimOllivier]

This fault happens after installing a service pack for ArcGIS.
There is no need to set the PYTHONPATH variable

1. Save the numpy folder in c:\python26\Desktop10.0\Lib\site-packages, or reinstall it again later.
    save the file from c:\python26\Desktop10.0\Lib\site-packages\Desktop10.pth

2. Remove Python and re-install python 2.6.6 in the standard location c:\python26

3. Reinstall Pythonwin with pywin32-216.win32-py2.6.exe

4. Copy the path file remaining that points to the arcpy module:
from
c:\python26\Desktop10.0\Lib\site-packages\Desktop10.pth
to
c:\python26\Lib\site-packages\Desktop10.pth

5. Reinstall numpy or move the numpy folder to c:\python26\Desktop10.0\Lib\site-packages

6. You can then delete the directory c:\python26\Desktop10.0 completely so that you only have one installation.

Test to see if Pythonwin opens with the correct version. Try opening the Python Help.
Test a script tool from ArcGIS using the os module.

Maybe this will be fixed at 10.1?

[yosukekimura]

I had the same issue with ArcGIS 10, and I have separate installation of python from activestate which I want to keep.  I have work around which goes like this:

1. Create a script called "fixpath.py" like follows



import sys
sys.path.extend(
"""C:\Python26_esri\ArcGIS10.0\Lib\idlelib
C:\Python26_esri\ArcGIS10.0\DLLs
C:\Python26_esri\ArcGIS10.0\lib
C:\Python26_esri\ArcGIS10.0\lib\plat-win
C:\Python26_esri\ArcGIS10.0\lib\lib-tk
C:\Python26_esri\ArcGIS10.0
C:\Python26_esri\ArcGIS10.0\lib\site-packages""".split())



2. Copy or save the file above as C:\Program Files\ArcGIS\Desktop10.0\arcpy\fixpath.py


3. Do whichever that applies




1. Script

When you run your script, have following line, before doing anything.


import fixpath



2. Python prompt from arcmap

type "import fixpath"

I came to this fix observing that

1. ArcMap's prompt still can find "sys"


2. By comparing sys.path output between Pythonwin (which I started from ArcGIS' program shortcut group) and Arcmap's python prompt, I noticed that all of those python directories are dropped somehow.

So I guess you can do similar by comparing sys.path of pythonwin and arcmap's python prompt, provided that they are using same python executable but the path got somehow screwed in arcmap. 

Caveats:

• Note that I specified to install python to c:\python26_esri when i installed arcgis, as I was using python2.6 at the time and i didn't want to overwrite it.  So match with yours, which is c:\python26 by default


• I observed entire arcmap drops dead when the script i added had error.  it happeded when I go into python command prompt.  I guess the prompt tries to see what names are available in python and then if it throws exception arcmap cannot handle it.  once i got script to fix (i forgot to import sys), the problem was gone.   So moral is to plan for to get out (which is to remove fixpath.py  and all reference to it from your scripts)