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

[Grégory Bataille]

You are completely right. Symbolic link. Don't know what I was thinking
about at the time!


On Wed, 25 Jan 2017 at 19:12, Kurt Schwehr <schwehr at gmail.com> wrote:

> Gregory,
>
> Aside: A point of terminology, by hyperlink, I think you mean symbolic
> link <https://en.wikipedia.org/wiki/Symbolic_link> or hard link.
>
> As a point of information, I'm using both python unittest and C++ gunit
> very effectively for GDAL.  I do use bazel as the build system, but that
> doesn't really matter.  A very behind copy of what I've done is here:
>
> https://github.com/schwehr/gdal-autotest2
>
> And, sadly, it looks like I've yet to get any of the python code in
> there.  I'll try to get at least something in there today.
>
> On Wed, Jan 25, 2017 at 3:35 AM, Grégory Bataille <
> gregory.bataille at gmail.com> wrote:
>
> 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
>
>
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
>
>
>
> --
> --
> http://schwehr.org
>
-- 
Greg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20170125/e34dac0f/attachment.html>