[GRASS-dev] proposal for g.search module

[Jachym Cepicky]

Well,

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'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 (there are line
breaks and quotes in the strings, what IMHO is really not good)

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?
Where to write tests for them? (I assume standard unittest package is being
used)
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?

Thanks

Jachym

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

>
> On Sun, Nov 29, 2015 at 7:06 AM, Jachym Cepicky <jachym.cepicky at gmail.com>
> wrote:
>
>> the code is in the same repository but packed in the g.search.module
>> directory now, not sure, if the g.extension will work again
>
>
> g.extension supports only directories which have Makefile, i.e. Makefile
> must be in the root directory of the repository. See r.modis (it might be
> more complicated then you need):
>
> https://trac.osgeo.org/grass/browser/grass-addons/grass7/raster/r.modis
> https://trac.osgeo.org/grass/browser/grass-addons/grass7/raster/r.green
>
> On Sun, Nov 29, 2015 at 4:06 PM, Jachym Cepicky <jachym.cepicky at gmail.com>
> wrote:
>
>> I've patched r3.info a bit (not sure, whether it's ok)
>> https://trac.osgeo.org/grass/changeset/66983/ for potential better
>> g.search.data output
>>
>
> Not really looked to the source code but with the commands:
>
> r3.mapcalc "test1 = rand(0, 1)" -s
> r3.flow in=test1 flowaccumulation=test2
> r3.info test2 -gh
>
> I get:
>
> ...
> description="generated by r3.flow"
> comments_0=comments_1=""
>
> (comments at the same row)
>
> BTW, have you considered writing a test? :)
>
> On Sun, Nov 29, 2015 at 4:06 PM, Jachym Cepicky <jachym.cepicky at gmail.com>
> wrote:
>
>>
>> i would like to move colorize, print_results from g.search.module to some
>> reachable place within existing grass python code base - any hint?
>>
>
> There are three options, not sure now what is better:
>
> grass.script.utils (scripting related, grass specific)
> grass.utils (more general functions, to be created)
> grass.tools (compilation, html related, to be created)
>
> We will need grass.tools at some point anyway to organize the code which
> now spreads over several files in tools and man directories.
>
> Not that you can also keep some functions in a "package directory" inside
> the addon like in r.modis but at least print_results looks like it should
> go to trunk.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20151130/d9b07025/attachment-0001.html>