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

[Moritz Lennert]

On 02/06/15 03:05, Vaclav Petras wrote:
> Hi all,
>
> I need opinions on how to resolve the question whether GRASS session can
> be started from another GRASS session.
>
> Here we want to use GISBASE from environment instead of build constant
> if available:
>
> https://trac.osgeo.org/grass/changeset/45576
>
> However, here we cause error when GISBASE already exists:
>
> http://trac.osgeo.org/grass/changeset/59210
>
> But the check was removed in:
>
> http://trac.osgeo.org/grass/changeset/59220
>
> because of:
>
> http://trac.osgeo.org/grass/ticket/2213
>
> The point of r59210 was to make impossible to start another GRASS
> session within an existing session.

Even though I see this happen regularly amongst my students, I'm not 
sure that I consider this such a problem to justify significantly 
changing the existing logic. Have you come across any serious issues 
related to this ?

The whole notion of a "session" is a bit misleading as all a "session" 
is (IIUC) is a specific state of environment variables. So if someone 
wants to switch GRASS version during a working session, this should 
remain possible by just changing these environment variables, i.e. after 
having launched trunk, switch to the grass70 release branch:

export 
GISBASE=/data/home/mlennert/SRC/GRASS/grass70_release/dist.x86_64-unknown-linux-gnu/
export 
LD_LIBRARY_PATH=/data/home/mlennert/SRC/GRASS/grass70_release/dist.x86_64-unknown-linux-gnu/lib/
export 
PATH=/data/home/mlennert/SRC/GRASS/grass70_release/dist.x86_64-unknown-linux-gnu/bin/:/data/home/mlennert/SRC/GRASS/grass70_release/dist.x86_64-unknown-linux-gnu/scripts/:/home/mlennert/.grass7/addons/bin:/home/mlennert/.grass7/addons/scripts:/home/mlennert/.grass7/addons/:/home/mlennert/BIN:/home/mlennert/BIN:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/opt/libreoffice/program:/home/mlennert/SRC/FWTools-2.0.6/bin_safe

or similar (there might be some other variables that need to be changed).

Why should this be bad ? But I see your argument that (in this case) the 
grass70 starting (better name would be "env_setup") script should 
actually force setting the GISBASE (and the others) to the path where 
grass70 is installed, instead of taking the existing setting from the 
environment, thus allowing easy switching of versions.

> However, r45576 is using exactly
> same check (GISBASE in env) to see if GISBASE is forced from outside.
> The two places for it are here:
>
> https://trac.osgeo.org/grass/browser/grass/trunk/lib/init/grass.py?annotate=blame&rev=65348#L48
> https://trac.osgeo.org/grass/browser/grass/trunk/lib/init/grass.py?annotate=blame&rev=65348#L1633
>
> I think starting non-interactive session (batch/exec mode) should be
> possible. Perhaps interactive session (--text & --gui) should have the
> check.

Non interactive sessions should always be possible since you can set all 
the env variables in the script and IIUC these will only be valid during 
the execution of the script.

>
> 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).

IIRC, this is just due to the check being in grass.py, but wingrass 
setting the env variable in the bat startup script.

> Moreover, this would disallow setting
> some GISBASE to system for scripting purposes ("without starting
> explictly") and then starting a standard session.
>
> The issue with the current state is that you cannot run different
> version of GRASS from a current session.

AFAIU, you can. You just have to set the env variables correctly.

> More serious issue is that you
> cannot start another version if you have GISBASE in your system
> environment for scripting purposes (as mentioned above).

If you don't want to have this problem, just don't set a system-wide / 
user-session wide GISBASE. You can always set it explicitely in your 
scripts.

> The current
> behavior may also differ depending on a platform.
>
> 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 would mean as I said above that calling the "starting" script of a 
specific version would always by default set the relevant variables to 
that version. I can agree to that.


> 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.

You mean that we would have some fallback mechanism allowing to 
overwrite the default from the command line (i.e. something like this: 
grass70 --use-env-variables) ?

I think this discussion is relevant, but please do not go through any 
premature changes before we haven't thought this through.

Moritz