[GRASS-dev] proposal for g.search module

Vaclav Petras wenzeslaus at gmail.com
Mon Nov 30 07:18:41 PST 2015


On Mon, Nov 30, 2015 at 3:27 AM, Jachym Cepicky <jachym.cepicky at gmail.com>
wrote:

> about the tests - generally yes, I'm writing it. Are you referring to
> r3.info or to g.search.* modules?  I could not found any example to
> r3.info tests
>

I meant r3.info as it is more critical but g.search.* is similar just not
critical.

https://grass.osgeo.org/grass71/manuals/libpython/gunittest_testing.html#tests-of-grass-modules
https://trac.osgeo.org/grass/browser/grass/trunk/raster/r.mapcalc/testsuite/test_r_mapcalc.py#L80
https://trac.osgeo.org/grass/browser/grass/trunk/lib/python/gunittest/testsuite/test_assertions.py


>
> I've rewritten r3.info so that the code is the same, as r.info (with -e
> flag) - but I can not tell, I'm satisfied with the result
>

I also cannot tell.

https://trac.osgeo.org/grass/changeset/66983
https://trac.osgeo.org/grass/changeset/66984


> (there are line breaks and quotes in the strings, what IMHO is really not
> good)
>

The comments, history or whatever it is is written as shell command for r
and r3, so the strings are in quotes (to be general) and long lines are
broken and continuation is done by backslash. With r3.info I now get:

comments="r3.flow input="test1" flowaccumulation="test2" unit="cell"
step=0.25\ limit=2000 max_error=1e-5 direction="down""

I'm not sure how exactly this compares to r.info. Vectors have this in some
better way but it's part of the format and I'm not familiar with it.


> My time resources allocatable to this task are slowly reaching to their
> end. I would need clear decision from you guys (since you are in charge to
> mess around GRASS code base):
>
> Where to put print_output & supporting functions?
>

print_output can go to lib/python/script/utils.py (grass.script.utils). The
others probably too, although I would mark them as experimental (not
guaranteed API).


> Where to write tests for them?
>

In a file in the testsuite directory at the level of the tested file, i.e.
lib/python/script/testsuite for lib/python/script/utils.py.

(I assume standard unittest package is being used)
>

unittest and grass.gnunittest, please see

https://grass.osgeo.org/grass71/manuals/libpython/gunittest_testing.html


> Can I omit g.search.data for now? (I would like to put some better code
> structure, as I can see it more clear now) - so I would put only
> g.search.module for now to GRASS trunk?
>

Sure.

Thanks! I'm looking forward to it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20151130/68ecfbb0/attachment.html>


More information about the grass-dev mailing list