[GRASS-dev] split GRASS (lib / cli / modules / wx / qt / web / etc.)

[Pietro]

Dear devs,

stimulated by the GSOC idea of Ondřej I would like to revive again this topic.
I know that this has been already discussed in the past, I found this
(CLI1=GUI [0]) but it is focused on users and packagers prospective.
Here I would like to face this point from a developer point of view.
As point out in previous threads GRASS it is already modular, but
(imho) there is duplicate code/functionalities and often things and
levels are mixed.

Let's start with a simple example: most of the GRASS modules, mix
nicely logic and cli, several of them have a single main function with
everything inside. I think could be useful to have a more clear
distinction between logic/algorithms and their public interface
(cli/gui). If we clearly split these two things the GRASS modules
became just an interface to some functions inside the GRASS libraries.

Another example is GRASS GUI that have internally a lot of
functionalities that (imho) should be moved|integrated to a
dedicated|existing python library, because their are independent by
the library (wx|qt|javascript+html5) used to render the final GUI, and
again to me it seems that a lot of things are mixed.

Split these main functionalities in different repository can help
developers, because they can focus/work on a smaller base of code.

So how to split GRASS. It  would be nice to open a dedicate repository
(git?) for each of this projects:

- grass-lib: provides only C and Python API. This component should be
a python citizen, I mean that should be available at the PyPI - the
Python Package Index [1] and of course install-able as python package
through pip;
- grass-cli: provides a shell (with no modules!), also available as a
pure python package;
- grass-modules: provides all the GRASS core modules (this could be
also a pure python interface calling functions in the C/Python
libraries), and could be split in other sub categories (e.g. imagery,
temporal, terrain, etc).
- grass-wx: provides a WxPython/Phoenix interface for GRASS
- (grass-qt: provides a PyQt/PySide interface for GRASS)
- (grass-jupyther: provides a Jupyther interface to GRASS)
- (grass-rest: provides a RESTful API for GRASS)
- (add your idea here... :-D)
- etc.

Each point is characterize by a different use-case and this things are
generally developed by different person with different backgrounds and
needs and to me it make sense to split them.

We could have a greater granularity and a clear focus for each
repository and could help to acquire new developers because it open
new GRASS' development possibilities.
Enlarging the use-case of GRASS. Separate things in dedicated
repository force developers to respect the distinction, and force them
to think where the code should be put/published.
Such subdivision could help has to reduce the total amount of code
making things more general and abstract. It should also help making
independent and well isolated tests.


It should also help the development cycle since we can release things
in a independently way, it requires only to specify in the
requirements.txt file a working tested combinations of python packages
versions.

{{{
numpy>=1.10
grass-lib>=8
grass-cli==8.1
grass-modules>=8
grass-wx=8.1.3
}}}

I think this idea could help mainly developers making things clear and
well organized in different sub-projects.
Opening the possibility to integrate GRASS functionalities to other
open-source projects.

This solution could help also in making things easier also for
packager and users, for example users could install GRASS on all the
system (win/Mac/*nix) running a single command:

{{{
$ pip install --user grass-lib grass-cli grass-modules grass-wx
}}}

What do you think?

All the best.

Pietro

[0] https://lists.osgeo.org/pipermail/grass-dev/2010-November/052661.html
[1] https://pypi.python.org/pypi