[GRASS-dev] [GRASS GIS] #2873: Simplify usage of GRASS in Python from outside

[GRASS GIS]

#2873: Simplify usage of GRASS in Python from outside
-------------------------+-------------------------------------------------
  Reporter:  wenzeslaus  |      Owner:  grass-dev@…
      Type:              |     Status:  new
  enhancement            |
  Priority:  major       |  Milestone:  7.1.0
 Component:  Python      |    Version:  svn-trunk
Resolution:              |   Keywords:  startup, installation, scripts,
                         |  interpreter, windows installer, pygrass,
       CPU:              |  temporal, bootstrap, boilerplate
  Unspecified            |   Platform:  All
-------------------------+-------------------------------------------------

Comment (by wenzeslaus):

 Replying to [comment:6 glynn]:
 > Replying to [ticket:2873 wenzeslaus]:
 >
 > > The `GRASS_EXECUTABLE` does not have to be set if `grass` is on the
 path or, in theory, if it is in on some standard path
 >
 > IMHO, this "solution" is yet more duct tape on top of the existing heap.

 I'll try to prepare some patch without this workaround which will expect
 `grass` executable, Python pakcages and libraries already on path. The API
 is the easy part here I guess.

 > Any real solution would start by simply deleting the GRASS startup
 script then figuring out what needs to be done to make everything still
 work without it.
 >
 > It should not be necessary to "start" GRASS.

 Back when you suggested that in #580 it seemed strange to me, but now I
 think it would be much better than the current situation.

 > On Unix, GRASS modules and libraries should be installed in system
 directories. Python packages should go in Python's site-packages
 directory. Environment variables should be set in /etc/profile (or
 whatever mechanism the distribution uses, e.g. /etc/profile.d).

 I can see this working for dynamic libraries and Python packages and I
 think this would be good enough for now, but how this would work for
 modules? For example, I have 141 PCL tools installed (`pcl_*`) but we have
 >500 modules plus addons which actually have to be on a separate site. It
 would be good to get opinions from some packagers.

 Anyway, dynamic libraries and Python packages in system paths are place to
 start. Can the compile/install process be set to this now?

 > GISRC should have a system-wide default setting such as
 $(HOME)/.grass/rc. Users who never need more than one session at a time
 can just use that file always, changing the database, location or mapset
 with g.mapset.

 For me this is different because it is related to the data being used and
 I'm not so convinced about it in comparison to the need for ready to use
 runtime environment. I often work in more then one Mapset and I actually
 use Mapset locks to see where I have already open sessions. However, I can
 see that for many users permanent connection to given Mapset plus a
 additional sessions (GISRCs) upon request (starting GRASS application or
 API in some special way) might work, although particular details matter a
 lot here.

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/2873#comment:8>
GRASS GIS <https://grass.osgeo.org>