<p dir="ltr">Hi Martin,</p>
<p dir="ltr">On Sun, Oct 4, 2015 at 2:30 PM, Martin Landa <<a href="mailto:landa.martin@gmail.com">landa.martin@gmail.com</a>> wrote:<br>
> Hi all,<br>
><br>
> when trying to fix all compilation and installation issues I replaced<br>
> get_lib_path() by set_path() [1]. These functions are not used in<br>
> GRASS core codebase. Their usage is not clear to me.</p>
<p dir="ltr">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 <a href="http://my.grass.module.py">my.grass.module.py</a> parm0=option0 param1=option1 -e --o).<br>
Since GRASS is changing the paths before and after compilations...</p>
<p dir="ltr">Surelly these functions can be implemented in a different way and/or improved.<br></p>
<p dir="ltr">> Fn get_lib_path() says "Return the path of the libname contained in<br>
> the module". So I would expect that it checkd that `modname` is a<br>
> directory and contains `libname` Python module. But 'libname' is just<br>
> used to check if it's a directory [2].</p>
<p dir="ltr">Yes, I think you are right, the function should check if libname is a directory or a python file.<br></p>
<p dir="ltr">> Only one function calls get_lib_path() - set_path() [3].<br>
><br>
> Can anybody here to clarify their usage?</p>
<p dir="ltr">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:</p>
<p dir="ltr">get_lib_path => Return a string with the path to the library, if found else return None<br>
set_path() => Set the python path to make the library importable or raise an exception</p>
<p dir="ltr">What do you think?</p>
<p dir="ltr">Pietro</p>