ok, thansk for the pointers on the deployment side. I'll think about it
--- Gregory Bataille On Wed, Jan 25, 2017 at 12:19 PM, Even Rouault <[email protected]> wrote: > 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 > > _______________________________________________ > gdal-dev mailing list > [email protected] > https://lists.osgeo.org/mailman/listinfo/gdal-dev >
_______________________________________________ gdal-dev mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/gdal-dev
