Opened 2 years ago

Closed 2 years ago

#3489 closed task (wontfix)

integrate grass session lib

Reported by: martinl Owned by: grass-dev@…
Priority: normal Milestone: 7.6.0
Component: Python Version: svn-trunk
Keywords: Cc:
CPU: Unspecified Platform: Unspecified

Description

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

Change History (6)

comment:1 Changed 2 years ago by martinl

Milestone: 7.5.07.6.0

Milestone renamed

comment:2 in reply to:  description ; Changed 2 years ago by 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?

comment:3 in reply to:  2 Changed 2 years ago by 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')

comment:4 in reply to:  description ; Changed 2 years ago by 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...

comment:5 in reply to:  4 Changed 2 years ago by 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).

comment:6 Changed 2 years ago by martinl

Resolution: wontfix
Status: newclosed

OK, closing as wontfix.

Note: See TracTickets for help on using tickets.