| | 9 | ==== Runtime, current location and mapset, execution ==== |
| | 10 | |
| | 11 | * C libraries and Python package(s) in system paths |
| | 12 | * Problem: |
| | 13 | * GRASS Python packages require things like grass_session package to be set up |
| | 14 | * This means than in between your imports you need to set up path to additional imports |
| | 15 | * GRASS C libraries require dynamic library path settings (and include settings when compiling) to be set up |
| | 16 | * Besides less convenience, this means that PyGRASS does not work even when both C and Python runtime is set up correctly because LD_LIBRARY_PATH change does influence the currently running process (only subprocesses). |
| | 17 | * Expected behavior: Most libraries and packages (and probably libraries of programs in general) are simply on standard system paths in unix-like environments. GRASS GIS should be accessible in the same way. |
| | 18 | * This is about the runtime environment, not about the connection to specific data or initialization of constants in C libraries. |
| | 19 | * Solution: |
| | 20 | * GRASS Python packages, C libraries and includes should install into standard paths thus being readily available for import (Python), execution (C), or includes. |
| | 21 | * On Linux/unix, make install and distributions need to be changed. |
| | 22 | * On Mac and Win, if you care about the above, you probably want to use Anaconda (or WSL) anyway, so this is how it should be distributed. Standalone and OSGeo4W installers should do the closest reasonable thing. |
| | 23 | * Additions: |
| | 24 | * Documented and short full initialization procedures for Python and C |
| | 25 | * Modules as subcommands |
| | 26 | * Given the above, should the GRASS GIS modules be "on path" as well? No, they should be subcommands where subcommand is something like the current `grass ... --exec` but perhaps with different syntax. |
| | 27 | * Looking at the GRASS GIS modules as subcommands does not change much directly right away, but clarifies how the API should be used and developed. |
| | 28 | * The db/location/mapset is then always expected to be set by `grass` command or another API and are not expected to run by themselves (this is starting to be already the case as people are adopting `--exec`). |
| | 29 | * The shell which starts with GRASS and the Console in GUI would be special cases where the subcommands are available without providing the actual GRASS command. |
| | 30 | * For tasks such as parallelization with tiling (or vectors) or imports and exports with reprojection require individual module calls to have different computational regions, mapsets or locations. This can be achieved by adding region and "gisrc" parameters to every module (i.e. to parser) or by providing this through `grass` command which needs to support most (if not all) of it anyway. |
| | 31 | * Subcommand interface would be then used inside GRASS Python code as well for the things which require it or potentially for everything (relying perhaps on the modules to be on path in addition to the libraries). Wrapping in Python functions expected with the current session being a special case (this open a way to all sorts of parallelizations and remote executions). Writing a GRASS modules would be a typical example of this special case (where perhaps the package uses internally the current session executor object as opposed to a generic one which requires to be initialized with db/location/mapset). |
| | 32 | * For the future, this allows us more flexibility, e.g. to implement addtional steps before or after module execution or to implement modules as C functions (and when called in a series, maps would not have to be written to disk or segment library storage could be transferred in between them). |
