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

[Kurt Schwehr]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20170125/2cf6ae88/attachment-0001.html>