[GRASS-dev] How GRASS should behave when another session is already active?

[Vaclav Petras]

On Tue, Jun 2, 2015 at 6:34 AM, Markus Neteler <neteler at osgeo.org> wrote:
>
> On Tue, Jun 2, 2015 at 3:05 AM, Vaclav Petras <wenzeslaus at gmail.com>
wrote:

> > Perhaps interactive session (--text & --gui) should have the
> > check.
>
> Definitely. IMHO there is no point in starting GRASS GIS as
> interactive session from within GRASS - only asking for troubles. Or
> is there any use case where this makes sense?

I cannot think of any but the issue might be how do we recognize we are in
a session versus somebody just have some variables set in system
environment and wishes to start GRASS in a regular way. Perhaps using GISRC
rather then GISBASE to see if we are in a session?

> > If the check is present (even just for the interactive sessions), the
> > OSGeo4W version (and probably standalone winGRASS too) is going to break
> > (needs to be changed somehow).
>
> Why does the OSGeo4W break? This is not clear to me.

Well, that's the part I'm not sure about. From the commits it seems that
OSGeo4W sets GISBASE ahead because the compile time path recored in
grass.py is wrong.

You can see `GISBASE=%OSGEO4W_ROOT%\apps\grass\grass- at VERSION@` in:

https://trac.osgeo.org/grass/browser/grass/trunk/mswindows/osgeo4w/env.bat.tmpl

Although there is nothing with GISBASE in:

https://trac.osgeo.org/grass/browser/grass/trunk/mswindows/env.bat

Perhaps forcing different GISBASE should be done using different variable
such as GRASS_GISBASE? GISBASE would mean GISBASE of currently running
session. GRASS_GISBASE would mean I wish to use use this path as GISBASE
next time I start GRASS session. But I'm not sure if I like it. It could
mess up the script on MS Windows a lot.

> > Moreover, this would disallow setting some
> > GISBASE to system for scripting purposes ("without starting explictly")
and
> > then starting a standard session.
>
> .. you mean in the non-interactive case.

No, I mean setting GISBASE into my system for convenient writing of scripts
which use "without starting explicitly" paradigm and then starting standard
session, interactive (--text, --gui) or non-interactive (--exec,
GRASS_BATCH_JOB). Any check for GISBASE as a proof of already running
session would disallow starting an actual session in this case (at least in
interactive mode if check is implemented only for the interactive mode).
Again, perhaps checking for GISRC rather then GISBASE is the way out.

Note that putting the variable into system environment is advantageous for
the scripts because it leads to scripts without hardcoded paths which can
be moved from machine to another. A lot of software, such as Java requires
you to set some environmental variables to enable using in command line or
in general.

However, in case of GRASS we can say that the best practive is to but the
executable on path and query executable for GISBASE (which is for example
needed for PYTHONPATH which is needed for import grass.script which is
needed for setup.init call).

> > The issue with the current state is that you cannot run different
version of
> > GRASS from a current session.
>
> ... yes, luckily :-)
>
> > More serious issue is that you cannot start
> > another version if you have GISBASE in your system environment for
scripting
> > purposes (as mentioned above). The current behavior may also differ
> > depending on a platform.
>
> Cannot we suggest to the user via test to remove that variable? Rather
> than overriding it?

Currently, as far as I understand, we are actually overriding it with
OSGeo4W (in the bat script, not grass.py which then uses it). On Linux, it
will be used. The warning would be always present with OSGeo4W.

Asking user to remove the variable would also mean that you would have to
put that to your scripts (which use "without starting explicitly"
paradigm). So maybe you wouldn't be required to set GISBASE but you would
have to delete it. This goes against my ultimate goal which is to make
"using GRASS modules from outside" easier.

But then again, perhaps the problem is that we check for a wrong variable.
I will try to discuss it more in answer to Moritz.

> > I'm not really sure what were the original intentions but I would
prefer to
> > switch the logic in r45576 and use GISBASE only if the path from compile
> > time does not exist. This allows to override current session (GISBASE
set in
> > some way) but allows to supply the GISBASE when there is something wrong
> > with compile time path. I would use some advice because I don't know how
> > this works on Windows and Mac nor what grass.sh file is supposed to do.
>
> I cannot comment yet on this unless I fully understand the issue (see
> questions above).
> Probably the pseudo-code should go into a trac page?

grass.py now has (pseudo-code):

if GISBASE in environment:
    current_gisbase = GISBASE path from environment
else:
    current_gisbase = GISBASE path set at compile time

According to mentioned commits and the env.bat.tmpl file it seems that
OSGeo4W goes to the first case because the compile time path is wrong.
Unfortunately, also in case of having GISBASE set in system to have it at
hand (as some people do on Linux), the first case applies and you many end
up in different version of GRASS then intended (GISBASE points to stable
release but you explicitly started trunk).

I suggested using GISBASE from environment as fallback:

current_gisbase = GISBASE path set at compile time
if current_gisbase does not exist:
    if GISBASE in environment:
        current_gisbase = GISBASE path from environment

But I'm not sure how reliable "current_gisbase does not exist" could be.

In this email I also suggested GRASS_GISBASE variable:

if GRASS_GISBASE in environment:
    current_gisbase = GRASS_GISBASE path from environment
else:
    current_gisbase = GISBASE path set at compile time

This would nicely solve the OSGeo4W case (special variable for a special
case), but I'm afraid it could also complicate the scripts (but perhaps
not?).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20150602/758df487/attachment-0001.html>