[GRASS-dev] g.extension not working on debian - grass 6.4.3svn

GRASS GIS GRASS GIS developer
1

Margherita wrote:

Hamish,
KUDOS! It works like a charm, tested with addons in C, in
python and in bash.
Thanks A LOT!

glad to hear it. It's just the first step though, making sure it
also still works from the various packages (esp. Mac) is needed.

Paulo, re.:

ERROR: G_getenv(): Variable LOCATION_NAME not set

I'd again ask Markus's question- are you trying to run the script
from outside of GRASS? The help pages get their usage info auto-
matically from a modified version of 'g.module --help', so if
you try to run it from outside of GRASS the module fails to run
and that's the error you are seeing. During the main build we
don't have a grass session to use for that so we employ a trick
that creates a fake grass session (called "demolocation", perhaps
a poor choice of words) and runs it there. The bootstrapping from
that to the installed stripped down build system for g.extension
and self compiled addon modules or self-supplied scripts is in large part the cause of all the trouble we've had with this, it's a multicontext situation. But solvable, and hopefully that part of it is all ok now.

regards,
Hamish

2

Hi Hamish,

No, I just run it from within GRASS. But let’s see if it works with the latest version (I’LLC try tomorrow).

Thanks!

Paulo

On Jan 28, 2013 10:14 PM, “Hamish” <hamish_b@yahoo.com> wrote:

Margherita wrote:

Hamish,
KUDOS! It works like a charm, tested with addons in C, in
python and in bash.
Thanks A LOT!

glad to hear it. It’s just the first step though, making sure it
also still works from the various packages (esp. Mac) is needed.

Paulo, re.:

ERROR: G_getenv(): Variable LOCATION_NAME not set

I’d again ask Markus’s question- are you trying to run the script
from outside of GRASS? The help pages get their usage info auto-
matically from a modified version of ‘g.module --help’, so if
you try to run it from outside of GRASS the module fails to run
and that’s the error you are seeing. During the main build we
don’t have a grass session to use for that so we employ a trick
that creates a fake grass session (called “demolocation”, perhaps
a poor choice of words) and runs it there. The bootstrapping from
that to the installed stripped down build system for g.extension
and self compiled addon modules or self-supplied scripts is in large part the cause of all the trouble we’ve had with this, it’s a multicontext situation. But solvable, and hopefully that part of it is all ok now.

regards,
Hamish

3

Just recompiled grass 6.4 (completely clean):

* The earlier mentioned problem with g.html2man not being in the right folder was solved, it appears in the tools folder now

* It did not solve the problem of omitting the parameter part in the manual page. When installing addons (tried script and py addons) using the g.extension gui interface (only showing the error messages):

...
ERROR: G_getenv(): Variable LOCATION_NAME not set
....
ERROR: G_getenv(): Variable LOCATION_NAME not set
...
WARNING: Unable to parse 'http://grass.osgeo.org/addons/grass6/modules.xml’. Metadata file not updated.
Installation of <r.csr> successfully finished

* The addon does not appear in the list when using the 'remove extension' gui interface

All is run from within GRASS (using the menu 'settings-addon extensions'). Just to be complete, running e.g, r.mess --html-description from the command line does give the expected html file with the NAME, KEYWORDS and SYNOPSIS sections (i.e., the ones left out in the manual tab).

Cheers,

Paulo

On Mon 28 Jan 2013 10:58:50 PM CET, Paulo van Breugel wrote:

Hi Hamish,

No, I just run it from within GRASS. But let's see if it works with
the latest version (I'LLC try tomorrow).

Thanks!

Paulo

On Jan 28, 2013 10:14 PM, "Hamish" <hamish_b@yahoo.com
<mailto:hamish_b@yahoo.com>> wrote:

    Margherita wrote:
    > Hamish,
    > KUDOS! It works like a charm, tested with addons in C, in
    > python and in bash.
    > Thanks A LOT!

    glad to hear it. It's just the first step though, making sure it
    also still works from the various packages (esp. Mac) is needed.

    Paulo, re.:
    > ERROR: G_getenv(): Variable LOCATION_NAME not set

    I'd again ask Markus's question- are you trying to run the script
    from outside of GRASS? The help pages get their usage info auto-
    matically from a modified version of 'g.module --help', so if
    you try to run it from outside of GRASS the module fails to run
    and that's the error you are seeing. During the main build we
    don't have a grass session to use for that so we employ a trick
    that creates a fake grass session (called "demolocation", perhaps
    a poor choice of words) and runs it there. The bootstrapping from
    that to the installed stripped down build system for g.extension
    and self compiled addon modules or self-supplied scripts is in
    large part the cause of all the trouble we've had with this, it's
    a multicontext situation. But solvable, and hopefully that part of
    it is all ok now.

    regards,
    Hamish

4

Based on remarks from Markus, I installed r.mess (and other extensions) from the command line rather then using the g.extension gui interface. It does seem to do the trick

The extensions install fine, and the total manual page is now rendered when running the extension. Meaning, including the NAME, KEYWORDS and SYNOPSIS sections (but, a minor thing, black square instead of grass icon - i.e., wrong link).

Not sure if it is of relevance, but if immediately after installing this way I run the extension from the command line, all works fine. Running it from the command console in the GRASS GIS Layer Manager does only work after restaring GRASS GIS though.

I didn’t realize that running g.extension from the menu invoked a different command (g.extension.py) then what used on the command line (g.extension). It does seem to make a difference. Sorry if that caused any confusion, but hope the above helps.

Also following a remark from Markus, I set the debug level at 3 with g.gisenv set=“DEBUG=3”. I attached the output from the command line when installing a extension.

debug.txt

Cheers,

Paulo

···

On Tue, Jan 29, 2013 at 11:17 AM, Paulo van Breugel <p.vanbreugel@gmail.com> wrote:

Just recompiled grass 6.4 (completely clean):

  • The earlier mentioned problem with g.html2man not being in the right folder was solved, it appears in the tools folder now

  • It did not solve the problem of omitting the parameter part in the manual page. When installing addons (tried script and py addons) using the g.extension gui interface (only showing the error messages):

…

ERROR: G_getenv(): Variable LOCATION_NAME not set

…
ERROR: G_getenv(): Variable LOCATION_NAME not set

…
WARNING: Unable to parse ‘http://grass.osgeo.org/addons/grass6/modules.xml’. Metadata file not updated.
Installation of <r.csr> successfully finished

  • The addon does not appear in the list when using the ‘remove extension’ gui interface

All is run from within GRASS (using the menu ‘settings-addon extensions’). Just to be complete, running e.g, r.mess --html-description from the command line does give the expected html file with the NAME, KEYWORDS and SYNOPSIS sections (i.e., the ones left out in the manual tab).

Cheers,

Paulo

On Mon 28 Jan 2013 10:58:50 PM CET, Paulo van Breugel wrote:

Hi Hamish,

No, I just run it from within GRASS. But let’s see if it works with
the latest version (I’LLC try tomorrow).

Thanks!

Paulo

On Jan 28, 2013 10:14 PM, “Hamish” <hamish_b@yahoo.com

mailto:[hamish_b@yahoo.com](mailto:hamish_b@yahoo.com)> wrote:

Margherita wrote:

Hamish,
KUDOS! It works like a charm, tested with addons in C, in
python and in bash.
Thanks A LOT!

glad to hear it. It’s just the first step though, making sure it
also still works from the various packages (esp. Mac) is needed.

Paulo, re.:

ERROR: G_getenv(): Variable LOCATION_NAME not set

I’d again ask Markus’s question- are you trying to run the script
from outside of GRASS? The help pages get their usage info auto-
matically from a modified version of ‘g.module --help’, so if
you try to run it from outside of GRASS the module fails to run
and that’s the error you are seeing. During the main build we
don’t have a grass session to use for that so we employ a trick
that creates a fake grass session (called “demolocation”, perhaps
a poor choice of words) and runs it there. The bootstrapping from
that to the installed stripped down build system for g.extension
and self compiled addon modules or self-supplied scripts is in
large part the cause of all the trouble we’ve had with this, it’s
a multicontext situation. But solvable, and hopefully that part of
it is all ok now.

regards,
Hamish