[GRASS-dev] proposal for g.search module

[Jachym Cepicky]

OK guys,

the script called g.search.module is now in trunk, I've added tests (Vašek:
they seem to be far too verbose to me, anything I could do about that?)

I've left the colorize and print_output functions in the file, reason:
better code structure would have to be implemented (read: IMHO decorator at
least for colorize should be used and I'm to doubt for now to get working)

still hope, it's ok for you as it is now, if not, just let me know

cheers and thanks for help

Jachym

po 30. 11. 2015 v 16:19 odesílatel Vaclav Petras <wenzeslaus at gmail.com>
napsal:

> 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/cc0d2ed5/attachment-0001.html>