Community Packages

Please read this before reporting a bug:
http://wiki.archlinux.org/index.php/Reporting_Bug_Guidelines

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

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
Task Type Feature Request
Category Packages
Status Closed
Assigned To Jaroslav Lichtblau (Dragonlord)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

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
Comment by Andrzej Giniewicz (Giniu) - Saturday, 24 December 2011, 09:39 GMT
Is it possible at all? I believe build process would have to be run twice, because python interpreter that is used for building/installing bindings is set since configure stage. Also, what about people who don't have python 3 installed, or try to keep the dependencies to minimum? Maybe correct solution would be to create split-package, like gdal, python-gdal and python2-gdal then? Though mentioned names would suggest that there is python package named gdal i.e. http://pypi.python.org/pypi/GDAL/ - so maybe python-gdal-bindings and python2-gdal-bindings? Anyway I don't believe it is a show stopper here, because it can be usually fixed by switching depending scripts from python to python2.

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.
Comment by Andrzej Giniewicz (Giniu) - Friday, 27 January 2012, 18:17 GMT
I just checked and found out, that the http://pypi.python.org/pypi/GDAL/ package is same as bindings included in gdal now. See http://trac.osgeo.org/gdal/wiki/GdalOgrInPython - "install from pypi" and "build --with-python" are listed as alternative ways to get same python bindings.

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).
Comment by Greg (dolby) - Monday, 19 November 2012, 06:59 GMT
Decision?

Loading...