4

I need to have GDAL/OGR working with Python 3.2 because of another dependency. However, I also want to have QGIS for convenience. However, QGIS - FWTools in particular is built against Python 2.5, so while most of QGIS works, I have none of the FWTools raster tools.

The error message I get is:

Couldn't load plugin GdalTools due an error when calling its classFactory() method

Traceback (most recent call last): File "C:/OSGeo4W/apps/qgis/./python\qgis\utils.py", line 138, in startPlugin plugins[packageName] = package.classFactory(iface) File "C:/OSGeo4W/apps/qgis/./python/plugins\GdalTools__init__.py", line 32, in classFactory from GdalTools import GdalTools File "C:/OSGeo4W/apps/qgis/./python\qgis\utils.py", line 283, in _import mod = _builtin_import(name, globals, locals, fromlist, level) File "C:/OSGeo4W/apps/qgis/./python/plugins\GdalTools\GdalTools.py", line 39, in raise ImportError( error_str ) ImportError: Module use of python32.dll conflicts with this version of Python.

Python version: 2.5.2 (r252:60911, Feb 21 2008, 13:11:45) [MSC v.1310 32 bit (Intel)]

I have tried using the QGIS Windows installer and the OSGeo4W installer and have Python 2.5 under the OsGeo4W folder. Is there an easy way of having the FWTools working correctly in QGIS and have GDAL/OGR working with Python 3.2?

In your answers you need to bear in mind that I am not familiar with compiling from source (sorry), but willing to learn if that is required and somebody can hold my hand through the process.

Thanks

MappaGnosis
  • 33,857
  • 2
  • 66
  • 129

3 Answers3

5

I had been putting off sorting this problem out for a long time but finally have a proper solution. The situation is this:

  • I need a 64bit version of Python 32 and GDAL for a package other than QGIS.
  • I need a 32bit version of GDAL to work with Python 2.7 for QGIS.
  • QGIS consistently loads the wrong DLL and complains that it is not a 32bit Windows application.

The reason and solution are simple. I have environment variables which point to the 64 bit GDAL installation - which was installed before QGIS and I need to leave alone so my other applications will work. OSGeo appends its path information to the system path but because it is put at the end of the path, my pre-existing installs for 64-bit Python 3.2 are always picked up. So, I added the following code at the start of the GdalTools.py file (I used the one in C:\Users\MyAccount.qgis\python\plugins\GdalTools):

# hack the path to force QGIS to look in OSGeo4w directory first
import sys
sys.path.reverse()

Now QGIS starts with zero errors and I can use the GDAL tools, without switching to another machine.

EDIT (Windows 64 bit version July 2014): I STILL have to do this hack because QGIS still uses Python27 and I need Python32 for other packages I use. I still get the same error message and forcing the paths in config section for QGIS still doesn't solve entirely the problem. However, this hack continues to neatly cure the issue (I am now editing the version of gdaltools.py in C:\OSGeo4W64\apps\qgis\python\plugins\GdalTools on my system.

MappaGnosis
  • 33,857
  • 2
  • 66
  • 129
  • Thanks for reporting back. It's good to have a final answer for this kind of questions. – underdark Jan 03 '13 at 18:32
  • Since this hack doesn't effect anything other than QGIS and effectively leaves the path intact, I think the QGIS developers could safely incorporate the change into the next release... but then again, if the long awaited 64-bit Windows installer binary becomes available - this hack will be redundant. – MappaGnosis Jan 04 '13 at 10:59
  • I'm not sure about the 64bit installer, but 32bit QGIS does not use the Windows system path variable (anymore?). Look into bin/o4w_env.bat, where a clean path variable is set. You could also hack bin/qgis.bat to get the path you really want. – AndreJ Jul 15 '14 at 15:04
  • That might be a change. The error I get is also still the same as per my third bullet point. QGIS is somehow trying to pick up the Python v3.2 dlls which are incompatible with Python 2.7 apparently. Anyway, I have a hack and can use the awesomely good QGIS package :). I shall certainly have a look at the .bat file you mention. Many thanks for the pointer – MappaGnosis Jul 15 '14 at 16:44
  • For clarity, it is not at the point of installation but afterwards where gdaltools.py tries to import GDAL. By reversing my path it picks up the the right location first. I have no idea why forcing QGIS to overwrite the PYTHONPATH variable in Settings->Options->Environment doesn't work unless it's an issue of scope perhaps. – MappaGnosis Jul 15 '14 at 16:48
  • +1 This worked for me on QGIS 2.16, which was failing to load the Processing plugin (Numpy, Scipy, etc). I have previous python installs from ArcGIS which added it's own flavor to my system path. I reversed the system path in the /init.py file of the processing plugin and everything now imports correctly. – Barbarossa Aug 30 '16 at 15:31
3

QGIS/OSGeo4W is shipped with its own copy of python, that as you noticed is the old 2.5. You don't need to install any other copy of python to have the gdal tools work in your QGIS copy.

[There is a ticket in the osgeo4w bug tracker asking to update python.]

Nevertheless there should not be any conflict between python installed with osgeo4w and any other python version you may have installed, unless you changed manually something in your osgeo4w installation.

Giovanni Manghi
  • 3,907
  • 16
  • 24
  • Yes, I knew about the OSGeo4W Python but my experience from trying this on three machines with pre-existing GDAL instalations is that, despite using that instaler, I still get the error message. It seems to work on the old versions of QGIS but not the most recent release. – MappaGnosis Dec 28 '11 at 11:58
  • can you please describe me the steps to replicate the issue? Example: install fwtools, install python 3.2, install osgeo4w -> qgis fail – Giovanni Manghi Dec 28 '11 at 13:01
  • Hi, Sorry for the slow reply! The steps were: Install Python3.2 -> install GDAL/OGR -> install osgeo4w -> qGIS fails. However, I wondered if it was something to do with the order of installation so I got a non-critical machine and reversed the order. That seems to work. I need to test this on another machine by un-installing everything and starting from scratch. – MappaGnosis Jan 05 '12 at 08:02
1

I finally bit the bullet and sorted this out. It is not the presence of Python that was the issue but GDAL. The order of installation is irrelevant.

QGIS is quite happy with another installation of Python but it is NOT happy with GDAL for Python 3.2. I tried setting the paths for GDAL in v1.9 as I thought this might resolve it but when GDAL fails on load, QGIS ignores your path settings and you also no longer have access to that function (which rather renders it a bit pointless).

I NEED GDAL in a Python 3.2 environment for something else but fortunately have another machine so I can have a QGIS machine and a Python32 machine :(

MappaGnosis
  • 33,857
  • 2
  • 66
  • 129