[GRASS-dev] wx.metadata installation issues & pygrass set_path() question
Pietro
peter.zamb at gmail.com
Sun Oct 4 22:36:31 PDT 2015
Hi Martin,
On Sun, Oct 4, 2015 at 2:30 PM, Martin Landa <landa.martin at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20151005/35442577/attachment.html>
More information about the grass-dev
mailing list