[GRASS-dev] GRASS SoC ideas wiki

[Markus Neteler]

On Sun, Mar 27, 2011 at 8:05 AM, Hamish <hamish_b at yahoo.com> wrote:
...
>  - "Design GRASS toolboxes environment, see GRASS repository layout proposal
>   for detailed information. This would also include general clean up and
>   organization of existing GRASS modules in trunk and add-ons."
>   -> We can't dump a student into such a contentious area without coming
>   to some consensus on the design ourselves first. Personally I consider
>   the breaking up of GRASS's 400 modules into a series of optional
>   toolboxes to be a massive mistake.

Why?

>  GEM already exists, but no one wants to use it,

.. because it is overkill (since some lines of script to almost the same).

>   g.extention is at its core fundamentally a hack (I say as a
>   coauthor), etc.--there's still a lot of maturing of ideas to do. The
>   wiki addons page is getting rather long, but we aren't on the scale of
>   needing something like CRAN yet..

For sure the *easy* integration of extra functionality is wanted by many
users. For sure also the possibility to "just" have the hydro part (or
whatever) of GRASS with a few clicks which would then also (ideally)
provide a GUI with only these modules in it.
I find that idea quite good.

>  - "Design sophisticated Python scripting interface for GRASS". -> I don't
>   get it. What is it? What would it do which python + grass.py doesn't
>   already?

Maybe you can but it is neither sufficiently documented (see all the related
questions) nor sufficiently structured/complete to be a Python API to GRASS
or whatever you want to call it.

Markus