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

[Grégory Bataille]

ok, I'll try to get a look


---
Gregory Bataille

On Sat, Jan 28, 2017 at 2:26 AM, Kurt Schwehr <schwehr at gmail.com> wrote:

> 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/20170128/de43f0ae/attachment.html>