FS#24379 - [gdal] Consider installing python bindings into python 3 as well
Attached to Project:
Community Packages
Opened by Bryce Nordgren (bnordgren) - Saturday, 21 May 2011, 17:43 GMT
Last edited by Jaroslav Lichtblau (Dragonlord) - Saturday, 18 May 2013, 16:22 GMT
Opened by Bryce Nordgren (bnordgren) - Saturday, 21 May 2011, 17:43 GMT
Last edited by Jaroslav Lichtblau (Dragonlord) - Saturday, 18 May 2013, 16:22 GMT
|
Details
Description:
Currently, gdal bindings are only installed in python 2. The upstream seems to believe they are compatible with python 3 as well. It'd be nice to have them available on all supported platforms. One effect of missing them in python3: postgis's compile script on trunk hardcodes "python" as the executable name, then fails to find the gdal python bindings because "python" isn't where they're installed. I did submit a patch to the postgis-svn AUR package which forces the compile to use the python2 executable. I also submitted an upstream bug on postgis about this. However, assuming this isn't addressed in the upstream, one of the easiest ways to nip this "looming problem" in the bud is to just have the gdal bindings available to the "python" executable, which means python3. :) Additional info: * http://pastebin.com/yAjxFV0S * http://trac.osgeo.org/postgis/ticket/970 |
This task depends upon
Closed by Jaroslav Lichtblau (Dragonlord)
Saturday, 18 May 2013, 16:22 GMT
Reason for closing: Won't implement
Saturday, 18 May 2013, 16:22 GMT
Reason for closing: Won't implement
Anyway, this question about python bindings is I believe deeper than just gdal (but any package that can provide python and python3 bindings or addons), and maybe should be considered more globally? For now I believe most packages choose one bindings over other bindings (like blender, which depends on python while it could be built for python2 without python dependency) - for example I could easily remove python from my system if it wasn't for 4 packages that depend on it, which could be built with python2 support as well.
So, I believe the best way is to provide packages gdal, python-gdal and python2-gdal, as separate (using pypi) or split packages (using --with-python).