Replying to [ticket:3489 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
Replying to [ticket:3489 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...
Replying to [comment:4 zarch]:
>
> Replying to [ticket:3489 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).