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

[Moritz Lennert]

On 18/03/16 12:58, Pietro wrote:
> 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.

In your opinion is this true at the module level, or mostly for the wxGUI ?


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

Why ? I really like the fact that each module works kind of like a 
high-level function with a defined public interface.

> If we clearly split these two things the GRASS modules
> became just an interface to some functions inside the GRASS libraries.

Many modules (if not most) are already that: a combination of GRASS 
library function calls in order to achieve the specific goal the module 
is set out for.

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

I agree that the GUI part is probably more subject to possible 
refactoring into a larger library part.

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

I'm not sure I like this extremely pythonic approach to GRASS. I love to 
use Python for scripting GRASS, but in my perception GRASS is far from 
being a Python project.


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

What is the difference between these modules and the existing ones ? 
Except for your idea to make all module Python modules.

> I think this idea could help mainly developers making things clear and
> well organized in different sub-projects.

I think I need more explanation in order to really understand what the 
advantage would be.

Currently everything resides in the same repository, but there is a 
distinction between modules (raster, vector, db, etc directories of the 
source tree), and libraries (lib).

I'm not sure what the great advantage of separating them would be, and 
honestly I'm afraid that if we start to have modules in versions that 
only run with specific version of a separate library package, we will 
have a flood of new user mails complaining about things not working. The 
current state of affairs at least guarantees that things are in sync.

> Opening the possibility to integrate GRASS functionalities to other
> open-source projects.

I don't know why other open-source projects cannot use GRASS 
functionality currently. There's pygrass if people want direct library 
access, you can always use system calls to modules, even more easily so 
with the new --exec parameter to the startup script.

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

I can already do that today in Debian:

apt-get install grass-core grass-gui grass-dev grass-doc

But that's a packaging issue.

> What do you think?

As I said, I find the whole approach a bit too Pythonic. Unless we 
decide that GRASS is going to become a Python project with a bit of 
C-libraries thrown in for performance, I need more convincing to buy this.

Moritz