I saw your recent comment in the set_path function:
{{{
TODO: why dirname is checked first - the logic should be revised
TODO probably also ‘path’ should be also removed - it’s used only by
compilation process for addons (see r.green for details)
}}}
‘path’ it is not used for compilation process for addons as you said. ‘path’ is used to run the code locally without compilation.
In this way it is possible to just unpack the module and call the sub-modules locally, compilation is not needed at all… This it is particularly useful during the development phase but not only. It works quite well also to overcome eventually g.extension problems.
Of course dirname must be checked before the default path, other wise it is too late…
On Tue, Jan 12, 2016 at 7:11 PM, Martin Landa <landa.martin@gmail.com> wrote:
hm, what means `dirname`? I got impression that it's used for
$GRASS_ADDON_BASE/etc/r.mymodule
is find by set_path('r.mymodule')
$GRASS_ADDON_BASE/etc/r.mymodule/lib1
is find by set_path('r.mymodule', 'lib1'). From this logic I don't
understand why dirname must be set. Martin
dirname must be set to check if the directory is available when using
the code locally, if dirname is available in the local specified path
then add the path to sys.path, otherwise try to find the correct path
within the GRASS standard paths.
I've added some more documentation to clarify this point.
In r67669 I moved the functions to grass.script.utils to avoid ctypes dependency. Backwards compatibility is kept. Documentation says depreciated. Old functions can be removed in 8.0.
hm, what means dirname? I got impression that it’s used for
$GRASS_ADDON_BASE/etc/r.mymodule
is find by set_path(‘r.mymodule’)
$GRASS_ADDON_BASE/etc/r.mymodule/lib1
is find by set_path(‘r.mymodule’, ‘lib1’). From this logic I don’t
understand why dirname must be set. Martin
dirname must be set to check if the directory is available when using
the code locally, if dirname is available in the local specified path
then add the path to sys.path, otherwise try to find the correct path
within the GRASS standard paths.
I’ve added some more documentation to clarify this point.
2016-01-25 21:05 GMT+01:00 Vaclav Petras <wenzeslaus@gmail.com>:
In r67669 I moved the functions to grass.script.utils to avoid ctypes
dependency. Backwards compatibility is kept. Documentation says depreciated.
Old functions can be removed in 8.0.
hm, what means dirname? I got impression that it’s used for
$GRASS_ADDON_BASE/etc/r.mymodule
is find by set_path(‘r.mymodule’)
$GRASS_ADDON_BASE/etc/r.mymodule/lib1
is find by set_path(‘r.mymodule’, ‘lib1’). From this logic I don’t
understand why dirname must be set. Martin
dirname must be set to check if the directory is available when using
the code locally, if dirname is available in the local specified path
then add the path to sys.path, otherwise try to find the correct path
within the GRASS standard paths.
I’ve added some more documentation
I’m still unsure whether we cover all cases correctly. Shouldn’t the compilation path options precede the normal ones?
On Mon, Jan 25, 2016 at 9:05 PM, Vaclav Petras <wenzeslaus@gmail.com> wrote:
In r67669 I moved the functions to grass.script.utils to avoid ctypes
dependency. Backwards compatibility is kept. Documentation says depreciated.
Old functions can be removed in 8.0.
