ok, I'll try to get a look
--- Gregory Bataille On Sat, Jan 28, 2017 at 2:26 AM, Kurt Schwehr <[email protected]> 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 < > [email protected]> 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 <[email protected]> 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 < >>> [email protected]> 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 < >>> [email protected]> 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 >>> [email protected] >>> https://lists.osgeo.org/mailman/listinfo/gdal-dev >>> >>> >>> >>> _______________________________________________ >>> gdal-dev mailing list >>> [email protected] >>> https://lists.osgeo.org/mailman/listinfo/gdal-dev >>> >>> >>> >>> >>> -- >>> -- >>> http://schwehr.org >>> >> -- >> Greg >> > > > > -- > -- > http://schwehr.org >
_______________________________________________ gdal-dev mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/gdal-dev
