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
_______________________________________________ gdal-dev mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/gdal-dev
