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
