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

[Rainer M Krug]

Pietro <peter.zamb at gmail.com> writes:

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

I am not a developer of GRASS but in my experience, it is very
advantageous to split one large package into smaller ones and I think
this is definitely a step into the right direction.

Just for clarifications: GRASS will still be available as a deb package
for Debian and derivatives, dmg, ... I hope? (pip makes me always a
little bit nervous - no idea why. Possibky it is another package manager
in addition to deb, rpm, dmg, homebrew, Macports, ...).

Also: It would see it as very important that grass can be installed on
all systems (as you mention - win, mac, *nix, ...?).

Cheers,

Rainer

>
> All the best.
>
> Pietro
>
> [0] https://lists.osgeo.org/pipermail/grass-dev/2010-November/052661.html
> [1] https://pypi.python.org/pypi
> _______________________________________________
> grass-dev mailing list
> grass-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev

-- 
Rainer M. Krug
email: Rainer<at>krugs<dot>de
PGP: 0x0F52F982
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 454 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20160318/894bd7ea/attachment.sig>