Hi Martin, On Sun, Oct 4, 2015 at 2:30 PM, Martin Landa <landa.mar...@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
_______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
