[gdal-dev] VRT derived band pixel functions written in Python

[Even Rouault]

Sean,

> 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 ;-)

> open
> 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
> programmer.

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.

Quoting
http://gdal.org/gdal_vrttut.html#gdal_vrttut_derived_python :

"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.

Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com