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

[Kurt Schwehr]

I just pushed a copy of all of the python unittest based tests that I have
so far to here:

https://github.com/schwehr/gdal-autotest2/tree/master/python

Be warned that I haven't tested them in this form and that in addition to
needing build infrastructure, I am pretty sure the code can't currently
find the test files.  Also a few of the NITF tests do not work in my custom
environment so there are a few untried test files in nitf_test.py.  And I
haven't tried these with python 3.x.

-kurt

On Wed, Jan 25, 2017 at 10:52 AM, Grégory Bataille <
gregory.bataille at gmail.com> wrote:

> 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
>



-- 
--
http://schwehr.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20170127/38f0aed3/attachment-0001.html>