[gdal-dev] [gdal2tiles.py] python engineering

[Even Rouault]

On mercredi 25 janvier 2017 05:48:00 CET Grégory Bataille wrote:
> Hello,
> 
> If I want to really spend some time for this utility, I'd like to do some
> clean engineering around it.
> What I'd like to do is:
> 
> - split the script into several files (smaller, single purpose, ...)
> --> can you confirm that on all target platform, all .py files are deployed
> and the /usr/local/bin/gdal2tiles.py is just an hyperlink on the source
> file installed somewhere else?

This depends pretty much on how GDAL is packaged.
On Unix, the default "make install" target will copy any .py file of swig/python/scripts/ to the 
${install_prefix}/bin directory. And for example Debian/Ubuntu packaging follows that.

On OSGeo4W, they do that similarly and have a .bat that creates a .bat shortcut for each 
installed .py file

> --> do you see any issue with that?

Yes, that the sub files would be available as executable scripts, whereas some of them would 
not be.

One could imagine that the code could go to a Python module (gdal_scripts ?), and the top-
level gdal2tiles.py could be something like:
from osgeo import gdal_scripts
gdal_scripts.gdal2tiles(...)

I'm not clear what the effort required / benefit would be however.

> 
> - Introduce a standard unittesting platform - pytest + tox I guess - (on
> top of the autotest thing, I would not attempt to redo them all) that would
> be incorporated in the CI

No opinion on that, having not used any of those. One must keep in mind that GDAL is not a 
pure python project, so not sure how those tools integrate well with the custom approaches 
we might have.

One thing that is missing currently, when comparing to the C++ part, is to get coverage 
information of the Python code.

> 
> - Clean up the code: follow PEP8 and fix pylint issues. Put PEP8 and pylint
> in the CI. Rename the hell out of the variables because I'm banging my head
> with rx, ry, lrux and the like :)
> 
> Any comments, warnings, problems you can think of?

Clearer variable names are always welcome.

Even


-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20170125/eddb48e0/attachment.html>