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 <wenzesl...@gmail.com> wrote: > > On Mon, Jul 17, 2017 at 12:36 AM, Pietro <peter.z...@gmail.com> wrote: > >> >> On Fri, Jul 14, 2017 at 6:00 PM, Vaclav Petras <wenzesl...@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
_______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev