[gdal-dev] VRT derived band pixel functions written in Python
even.rouault at spatialys.com
Thu Sep 15 07:13:12 PDT 2016
> I suspect users will be find it very surprising if `which python` and the
> python interpreter used by VRT are not the same
Yes, we should probably make some effort to use the same python version as the
one that comes as default given the PATH. I've just opened
https://trac.osgeo.org/gdal/ticket/6652 regarding this.
> . Imagine starting python in
> an environment created by virtualenv or conda that contains extension
> modules like scikit-image, scikit-learn, &c. You import osgeo.gdal,
or rasterio ;-)
> your super duper VRT with `gdal.Open()`, and get an error because your
> environment's extension modules aren't available in the VRT script. This
> could be tough to debug for a beginning to intermediate level Python
In the situation you describe here, things will work as expected. External
"libpythonXX.so" or the one specified by PYTHONSO are only tried *after*
checking if the process has already the Python symbols loaded.
"When GDAL will need to run Python code, it will first determine if the Python
interpreter is loaded in the current process (which is the case if the program
is a Python interpreter itself, or if another program, e.g. QGIS, has already
loaded the CPython library). Otherwise it will look if the PYTHONSO
configuration option is defined. [...] If the PYTHONSO configuration option is
not defined, then a predefined list of shared objects will be tried [...]"
This order is strictly needed and was not what I implemented first. My first
attempt honoured PYTHONSO first, but then if you did things like
"PYTHONSO=libpython3.1.so python2.7 read_my_vrt.py", this crashed due to
conflicting symbols being imported.
Spatialys - Geospatial professional services
More information about the gdal-dev