integrate grass session lib

[martinl]

Hi,

it would be nice to integrate Python grass_session lib (1) into GRASS code base. For G76 imported simply by

from grass.session import Session

What do you think?

(1) ​https://github.com/zarch/grass-session

[martinl]

Milestone renamed

[hellik]

Replying to martinl:

Hi,

it would be nice to integrate Python grass_session lib (1) into GRASS code base. For G76 imported simply by

from grass.session import Session

What do you think?

(1) ​https://github.com/zarch/grass-session

looks interesting.

a quick scrolling over the code

e.g.

DEFAULTBIN = "grass{version}"
DEFAULTGRASSBIN = dict(win32="C:\OSGeo4W\bin\grass{version}svn.bat",
                       darwin=("/Applications/GRASS/"
"GRASS-{version[0]}.{version[1]}.app/"))

    def get_platform():
        if sys.platform == "win32":
return "win32

        config_dirname = "GRASS7"
    if platform == "win32":
        config_dir = os.path.join(os.getenv('APPDATA'), config_dirname)
        env['PATH'] += os.pathsep + os.path.join(gisbase, 'extrabin')
        env['GRASS_PYTHON'] = env.get('GRASS_PYTHON', "python.exe")
env['GRASS_SH'] = os.path.join(gisbase, 'msys', 'bin', 'sh.exe')

maybe some finetuning regarding win 32bit/64bit and OSGeo4W/standalone winGRASS is needed?

[hellik]

Replying to hellik:

Replying to martinl:

Hi,

it would be nice to integrate Python grass_session lib (1) into GRASS code base. For G76 imported simply by

from grass.session import Session

What do you think?

(1) ​https://github.com/zarch/grass-session

looks interesting.

a quick scrolling over the code

e.g.

DEFAULTBIN = "grass{version}"
DEFAULTGRASSBIN = dict(win32="C:\OSGeo4W\bin\grass{version}svn.bat",
                       darwin=("/Applications/GRASS/"
"GRASS-{version[0]}.{version[1]}.app/"))

    def get_platform():
        if sys.platform == "win32":
return "win32

        config_dirname = "GRASS7"
    if platform == "win32":
        config_dir = os.path.join(os.getenv('APPDATA'), config_dirname)
        env['PATH'] += os.pathsep + os.path.join(gisbase, 'extrabin')
        env['GRASS_PYTHON'] = env.get('GRASS_PYTHON', "python.exe")
env['GRASS_SH'] = os.path.join(gisbase, 'msys', 'bin', 'sh.exe')

maybe some finetuning regarding win 32bit/64bit and OSGeo4W/standalone winGRASS is needed?

regarding 32bit/64bit

e.g.

import platform
platform.architecture()
('64bit', 'WindowsPE')

[zarch]

Hi Martin,

Replying to martinl:

it would be nice to integrate Python grass_session lib (1) into GRASS code base.

First of all I'm fine if we want to integrate grass_session into the grass code.

However, for me the main advantage of grass_session library is that it is a "standard" python library, that is installed to the python interpreter as other libraries do. Once that you have installed it, you can open your python interpreter and use it without the need of setting python paths, etc.

If we include the grass_session to GRASS, then to be able to use the library we need to set the python path... I developed this small library because I don't want to set the python path in every script that I'm writing (duplicating the code... and fixing the same code multiple times), I would like to have a good multi-platform/tested code that I can simply import and use it, and If I have to fix something I have only a single piece of code to read/debug/fix.

The other advantage to have as an external library is that it should be compatible with different GRASS7* versions.

Include the grass_session into GRASS code would add the ability to manage multiple GRASS sessions on different locations/mapsets... that can still be useful some how, but the library was developed to avoid to set the python path for every script, and perhaps should be redesign/rethink...

[wenzeslaus]

Replying to zarch:

Replying to martinl:

it would be nice to integrate Python grass_session lib (1) into GRASS code base.

However, for me the main advantage of grass_session library is that it is a "standard" python library, that is installed to the python interpreter as other libraries do. Once that you have installed it, you can open your python interpreter and use it without the need of setting python paths, etc.

Agreed. Although I'm not sure how to put it together with GRASS GIS libraries (in relation to code/distribution), the separate library promises better, more convenient, use for the end user.

See also #2873 for an extensive discussion. One alternative solution is to put GRASS libraries (Python and C) on path (see #2873 and also #2424).

[martinl]

OK, closing as wontfix.