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

Pietro peter.zamb at gmail.com
Tue Jul 18 22:42:34 PDT 2017


Hi Vaclav,

sorry for the delay but in the last day I was off-line.

On Mon, Jul 17, 2017 at 5:36 PM, Vaclav Petras <wenzeslaus at gmail.com> wrote:

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

Nice module, I was not aware of it!
However I think that the purpose is slightly different. The grassession
aims is to generate the session remotely, here I would like to setup a
local session. It is true that I should be able to just connect through ssh
to the localhost... but it seems to me not the right way. So I've sketch a
possible implementation just to see how it could work, see:

https://git.osgeo.org/gogs/zarch/grass/commit/b9cb69a1d7381924b0c2229ba43f21b1b7473c72



>
>
> *# 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
>

Thank you


from grass.init import Session
>>
>> # 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).
>

Sorry I'm not sure that I get your point here, what do you mean?
The following code is running at the moment on my machine:

```python
import os
import sys

MAPSET = '/home/pietro/docdat/gis/nc_basic_spm_grass7/user1/'
GISBASE = '/home/pietro/docdat/src/gis/ggrass/dist.x86_64-pc-linux-gnu/'

# set the path
sys.path.append(os.path.join(os.environ.get('GISBASE', GISBASE),
                             'etc', 'python'))

# import the python GRASS libraries
from grass.script.core import run_command
from session import Session


with Session(MAPSET) as session:
    run_command('r.slope.aspect', elevation='elevation',
                slope='slope', aspect='aspect',
                overwrite=True)
```


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

I was thinking to add this Session class definition inside init/session.py
to then try to refactor the main function in parser.py:

https://git.osgeo.org/gogs/zarch/grass/src/grass_session/lib/python/init/parser.py#L189

to start a session and then execute all the rest of the functions to
start/use the grass shell/gui.


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

I'm not sure too! This is why I'm trying to sketch some code drafting to
understand what is feasible and how should this organized.
Thank you for taking time to review the code/changes and to give me
feedback.

Cheers

Pietro
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20170719/1db5dfe6/attachment.html>


More information about the grass-dev mailing list