4

I'm attempting to launch Python 2.5 from Python 2.6. The reason for this is a compiled library I'm trying to use (GDAL) isn't supported for the version of Python distributed with another program (ArcGIS).

Here's what I'm attempting to do. The main.py file in Python 2.6:

import subprocess
p = subprocess.Popen(['C:\OSGeo4W\gdal_python_exec.bat', 'X:\\local\\import_tests.py'])

gdal_python_exec.bat is a windows batch script that fires up the 2.5 version of Python I want while also setting up some environment variables:

@echo off
set OSGEO4W_ROOT=C:\OSGeo4W
PATH=%OSGEO4W_ROOT%\bin;%PATH%
for %%f in (%OSGEO4W_ROOT%\etc\ini\*.bat) do call %%f
@echo on

@C:\OSGeo4W\bin\python.exe %1

import_tests.py tries to import gdal:

try:
    from osgeo import gdal
    raw_input('Imported! (Press enter)')
except Exception, e:
    print(e)
    raw_input('Failed! (Press enter)')

When I run main.py at a DOS command line as python.exe main.py (that's Arc's 2.6 version of python), things work fine. However, if I take the same script and add it as a 'toolbox' inside the main application and launch it from there, I get a "DLL not found" for the GDAL lib inside the import_tests.py file!

How can this happen when subprocess is the module that's launching a different Python interpreter? Any ideas on what could be happening?

Edit: I can verify that the os.environ['PATH'] variables are the same in both calls.

Edit2: The C:\Program Files\ArcGIS...\Bin directory contained a dll that wasn't compatible with my python bindings. Windows searched the cwd first and attempted to load that dll, failed, then reported a "dll not found" error.

Rich
  • 12,068
  • 9
  • 62
  • 94
  • What GUI are you using for the main application? What dlls does gdal try to load? Do any of them load successfully? – Velociraptors Aug 19 '11 at 21:46
  • The main GUI is ArcGIS. As far as I know `gdal` tries to load `gdal.dll`, but I'm not sure how I would find out. How can I check? – Rich Aug 19 '11 at 21:52
  • You can use [Process Explorer](http://technet.microsoft.com/en-us/sysinternals/bb896653) to see which DLLs a particular process has loaded. In this case, you'll probably want to check ArcGIS and all Python processes. Given your original problem, I'd say it's most likely that ArcGIS is poisoning something, *not* python. – Velociraptors Aug 21 '11 at 17:40

2 Answers2

1

Regardless of whether PATH is correct, a simple test would be to change to a different arbitrary directory and do python.exe C:\full\path\to\main.py. If that reproduces the problem then you know it's some sort of path problem.

Check sys.path, I'll bet that's where the difference is. If that's the case, you probably need to alter the way you make your Python code and libraries are accessible from python.exe, either using the site module or using something else like zc.buildout/zc.recipe.egg's support for generating console_scripts with the correct sys.path baked in.

Ross Patterson
  • 5,702
  • 20
  • 38
  • Thanks for the help, but sys.path is identical between the two calls except for an extra directory. If I manually remove that directory I still get the same error. I've also tried calling the script by absolute path like you suggested, but still nothing. Do you have any other ideas I could check? – Rich Aug 19 '11 at 21:07
  • Yes, that was the problem. Apparently the cwd when run from the GUI was in a directory that had a different version of the same dll. Things work again when I change away from that directory to anywhere else. – Rich Aug 22 '11 at 16:22
1

It appears from comments posted elsewhere that

"The working one is C:\Windows and the broken one is C:\Program Files\ArcGIS...\Bin."

Do a os.chdir to make it work.

[No idea what this really means, the comment was hard to parse.]

S.Lott
  • 384,516
  • 81
  • 508
  • 779
  • The `C:\Program Files\ArcGIS...\Bin` directory contained a dll that wasn't compatible with my python bindings (I'm not sure why, windows isn't my thing). Windows searched the cwd first and attempted to load that dll, failed, then reported a "dll not found" error. – Rich Aug 22 '11 at 17:04
  • @Rich: This kind of information doesn't belong in comment. It's an **essential** part of the question. Please **Update** the question to include this essential fact. – S.Lott Aug 23 '11 at 09:51