Support GDAL Python binding in OTB standalone packages
Short summary of the requested feature:
OTB packages provides a standalone environment to access to OTB features, especially otb applications. Moreover the application integrates Python bindings to wrap otb applications in a Python script.
It would be nice if the package also integrates Python bindings of GDAL. It will provide users the ability to use jointly otb app and gdal functionalities in the same Python environment.
Technically, OTB superbuild allows to pass extra options for internal gdal configuration:
There is probably something else to do to deploy GDAL Python libraries in the OTB package.
Activity
adding gdal python bindings is essential. This issue had popped up many times and thanks for making a formal feature request. The issue to deal is how to handle multiple python versions. Note that this is also the case with otb also. so I propose to provide a simple script in package that allows uses to build python bindings. It will save us from choice of what-python-version-users-can-use.
Users of python bindings are already fixed with a python version in their own big projects. So giving only "N" supported versions of python make people feel uneasy.
Thanks Rashad, what you propose could be complementary I think:
-
Provide gdal bindings for Python 2 or 3 out of the box in the binary package as it will allows otb users or participants to otb tutorials to test otb python bindings jointly with gdal. It will not be satisfy all users but will help to demonstrate the potential of OTB jointly with other libs like gdal, numpy...
-
Provide a mechanism in the package to build and deploy bindings for specific versions of Python for more advance users who want to integrate OTB in their own projects which rely on a specific version of Python
-
-
@mgrizonnet well, its a bit tricky when you deal with python and you have modules that load shared libraries. This is why projects such as Anaconda and Sen2Cor distribute their own python. I understand you are taking this in a user perspective and I agree your solution is useful in tutorial sessions, hackfest etc..
My point is we don't know what all versions of python used. For all shared libraries and executable, we already demand a minimum version of c and c++ libs and any version higher than that is guaranteed to work!. That is good news part of it.
In Python world things are not so sure. So we end up in a tutorial session where users run python script and it crash exactly at app.ExecuteAndWriteOutput() while the same thing on command line and monteverdi is working. And nobody knows what is going and is not possible to debug.
Yes the other solution needs some "extra" work which can be considered "bad" or destroy purpose of binary packages. Each has its own advantages. If I were given a choice I would go with right solution. You have to try each of them and see which has more number of crash/bug reports submitted.
python bindings are special case in OTB and is a only wrapper over application engine. So I wouldn't count them more than that.
added Doing label
Quick status: I enabled GDAL python wrapping on several platforms
- On MacOS: installation do not work. I need to push a SuperBuild patch for GDAL so that it will use the right prefix
- On CentOS: wrong installation dir, the python modules goes to
INSTALL_PREFIX/lib64/..., I will also try to find a patch
-
Work is almost done for MacOS and Linux. Now is Windows...
It appears that to compile GDAL bindings for Python 2.7 on Windows, you need a specific compiler (http://aka.ms/vcpython27). So for now, I have rather tried Python 3.5, which seems to compile (after tweaking the makefile.vc). I will probably switch all other platforms to Python 3.5 to be consistent...
-
@gpasero, description of "special" compiler package seems interesting to try. "This compiler package is entirely unsupported and represents a snapshot of the last version that is fully compatible with Python 2.7. For the latest security and bug fixes, please use the latest version of Microsoft Visual Studio for any development work that does not directly interface with Python 2.7." Is that same with py3?
mentioned in merge request !38 (merged)
-
What I observed is:
-
_gdal.sodoesn't link to any python library - however it does contain symbols imported from Python.
- When you try to "dlopen" this library: it fails
- When you do "dlopen" on Python interpreter, then dlopen on
_gdal.so: it works
This is maybe a trick to avoid a hard dependency on Python libraries.
-
mentioned in merge request !78 (merged)
changed milestone to %7.0.0
removed To Do label
mentioned in issue s1-tiling/s1tiling#41 (closed)
