[GRASS-dev] wx.metadata installation issues & pygrass set_path() question

Hi all,

when trying to fix all compilation and installation issues I replaced
get_lib_path() by set_path() [1]. These functions are not used in
GRASS core codebase. Their usage is not clear to me.

Fn get_lib_path() says "Return the path of the libname contained in
the module". So I would expect that it checkd that `modname` is a
directory and contains `libname` Python module. But 'libname' is just
used to check if it's a directory [2].

Only one function calls get_lib_path() - set_path() [3].

Can anybody here to clarify their usage?

Thanks, Martin

[1] https://trac.osgeo.org/grass/changeset/66408
[2] https://trac.osgeo.org/grass/browser/grass/trunk/lib/python/pygrass/utils.py#L303
[3] https://trac.osgeo.org/grass/browser/grass/trunk/lib/python/pygrass/utils.py#L319

--
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa

On Sun, Oct 4, 2015 at 8:30 AM, Martin Landa <landa.martin@gmail.com> wrote:

when trying to fix all compilation and installation issues I replaced
get_lib_path() by set_path() [1]. These functions are not used in
GRASS core codebase. Their usage is not clear to me.

The replacement was probably a good choice. In theory they could be used in core, but core scripts are usually shorter, so they fit to one file. Addons are larger, so they need libraries/packages/modules.

Fn get_lib_path() says “Return the path of the libname contained in
the module”. So I would expect that it checkd that modname is a
directory and contains libname Python module. But ‘libname’ is just
used to check if it’s a directory [2].

Not sure if I can actually clarify. However, when running module which has libraries when running it directly from source, when using make, and when it is installed in addons one needs different path setup or imports. Theget_lib_path() finds where the library/package/module is. By itself get_lib_path(), it required still some set up, so set_path() was added. What the functions should be actually doing and what part of what they are doing is useless is unclear. All depends on also on makefiles and that’s the reason for #2132 [1] as well as for r66411 [2], I suppose.

Only one function calls get_lib_path() - set_path() [3].

That’s right. There is no need to call it anywhere else. get_lib_path() is used to get the existing/right path to the library.

Can anybody here to clarify their usage?

Every time I’ve tried to make to understand it I failed. I’ve tried to make it work for different published and unpublsised addons and what works on one occasion (e.g. local make) did not work in other (e.g. addons). I guess good example of the same is log of the r.modis addon makefiles [3, 4] as well as import changes.

Sorry,

Vaclav

[1] https://trac.osgeo.org/grass/ticket/2132
[2] https://trac.osgeo.org/grass/changeset/66411
[3] https://trac.osgeo.org/grass/log/grass-addons/grass7/raster/r.modis/Makefile
[4] https://trac.osgeo.org/grass/log/grass-addons/grass7/raster/r.modis/libmodis/Makefile

Thanks, Martin

[1] https://trac.osgeo.org/grass/changeset/66408
[2] https://trac.osgeo.org/grass/browser/grass/trunk/lib/python/pygrass/utils.py#L303
[3] https://trac.osgeo.org/grass/browser/grass/trunk/lib/python/pygrass/utils.py#L319

Hi Martin,

On Sun, Oct 4, 2015 at 2:30 PM, Martin Landa <landa.martin@gmail.com> wrote:

Hi all,

when trying to fix all compilation and installation issues I replaced
get_lib_path() by set_path() [1]. These functions are not used in
GRASS core codebase. Their usage is not clear to me.

The idea is to be able to execute the same code in both scenarios: compiled/installed code, and executing the python code locally (e.g. python my.grass.module.py parm0=option0 param1=option1 -e --o).
Since GRASS is changing the paths before and after compilations…

Surelly these functions can be implemented in a different way and/or improved.

Fn get_lib_path() says “Return the path of the libname contained in
the module”. So I would expect that it checkd that modname is a
directory and contains libname Python module. But ‘libname’ is just
used to check if it’s a directory [2].

Yes, I think you are right, the function should check if libname is a directory or a python file.

Only one function calls get_lib_path() - set_path() [3].

Can anybody here to clarify their usage?

They are split for code-granularity reasons and potential re-usability, Every time that you need to set/modify the python path you need the get_lib_path and modify the python path, but i think that sometime could be also useful to just check the path to the library without changing the python path. Therefore the idea here is:

get_lib_path => Return a string with the path to the library, if found else return None
set_path() => Set the python path to make the library importable or raise an exception

What do you think?

Pietro