Pietro <peter.z...@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@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-dev -- Rainer M. Krug email: Rainer<at>krugs<dot>de PGP: 0x0F52F982
signature.asc
Description: PGP signature
_______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev