[GRASS-dev] move everything from /lib/init/grass.py to /lib/python/init

Vaclav Petras wenzeslaus at gmail.com
Mon Jul 17 08:36:07 PDT 2017


On Mon, Jul 17, 2017 at 12:36 AM, Pietro <peter.zamb at gmail.com> wrote:

>
> On Fri, Jul 14, 2017 at 6:00 PM, Vaclav Petras <wenzeslaus at gmail.com>
> wrote:
>
>> This is exactly what I had in my mind when doing the last major changes
>> in the grass.py file.
>>
> I generally like the layout you suggested. It seems to me that choosing a
>> good name for the whole module will be a bit tricky.
>>
>
> This is intended as a proof of concept to see the feasibility.
> I've try to found a better name but didn't come up to my mind...
> Perhaps: session instead of init?
>
> My final objective is to be able to do something like:
>

That makes sense. In fact, that's very similar to a file I drafted some
time ago splitting the data initialization and runtime in
grass.script.setup and adding Session (see the attached file). Another
example, for a different case, is here:

https://github.com/wenzeslaus/g.remote/blob/master/grasssession.py

*# Perhaps in GRASS8 we will be able to skip this! ;-)*
> sys.append(os.environ.get('GISBASE', '/home/pietro/my/gisbase'))
>

Added to the list, but how to do it remains unclear (many different
discussions in Trac and ML):

https://trac.osgeo.org/grass/wiki/Grass8Planning


>
> from grass.init import Session
>
> # open - close mode
> session = Session('mygisdbase/location/mapset')
> session.open()
> # do my stuff here...
> session.close()
>
> # with statement
> with Session('mygisdbase/location/mapset') as session:
>     # do my stuff here
> ```
>
>

Unfortunately, here is where the trouble begins. The above leads to the
following:

with Session as session:
    session.run_command(...)

which fits with API which already exists for Ruby:

https://github.com/jgoizueta/grassgis/

GrassGis.session configuration do+
    r.info 'slope'
    g.region '-p'
end
The trouble is that session (at least in Python) needs to depend on the
rest of the library because it is the interface for the rest (on demand
imports may help here).

So perhaps having grass.init or grass.setup with the low level functions
and then a separate grass.session with a nice interface which may depend on
all other modules may be a better way. (Although having each function from
the library as a method of Session calls for more thinking about
grass.session.Session.

Just to be clear: I definitively think this should be done. I'm just not
sure what is the right way.

Vaclav
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20170717/c46cadd1/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: __init__.py
Type: text/x-python
Size: 16560 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20170717/c46cadd1/attachment-0001.py>


More information about the grass-dev mailing list