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

[Grégory Bataille]

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 <even.rouault at spatialys.com>
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
> gdal-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20170125/efee2c21/attachment-0001.html>