[GRASS-dev] Should we see GRASS as an application ? [was: Re: [GRASS-user] Error in pansharp tool: missing grass.script]

[Moritz Lennert]

[Moving this to grass-dev as this is a more fundamental issue]

On 26/06/15 15:59, Vaclav Petras wrote:
> On Fri, Jun 26, 2015 at 4:33 AM, Moritz Lennert
> <mlennert at club.worldonline.be <mailto:mlennert at club.worldonline.be>> wrote:
>
>     On 26/06/15 04:20, Vaclav Petras wrote:
>
>         GRASS modules run only in the proper environment which is best
>         ensured
>         by actually running GRASS.
>
>
>     As elsewhere we are in discussions about good practice and making
>     things clearer, I'd just like to slightly modify this statement:
>
>     "GRASS modules run only in the proper environment which is easiest
>     to set up by actually running the grass 'startup' script."
>
>     GRASS is not a program, and, therefore, cannot be "run" as such.
>
>     Just being pedantic, I know... ;-)
>
>
> Being pedantic I don't think you are right. We've already discussed this
> together and I think that although you can set the proper environment
> yourself, there are some additional things which the grass.py is doing
> (like locking Mapset on Linux), so then there is something which is
> actually running. Moreover, the environment is relatively complex (a lot
> of variables + a file) and although this does not make the setup script
> an application, it is more practical to thing about it as an application
> because it better describes the challenge you face when setting up the
> environment yourself (that it is a big challenge can be inferred from
> monstrous wiki page and number of questions on this topic on list, GIS
> SE and SO as well as bug trackers of other applications like QGIS).
> Finally, you execute `grass`, you execute things inside it, and end
> `grass` (classic usage) or `grass` executes things for you (--exec and
> GRASS_BATCH_JOB). This should like a program which runs, therefore it is
> an program which runs ("it looks like a duck...").
>
> The last approach has its limits when GRASS is considered as an
> interpreter which should work with shebang [1], but just because of that
> I wouldn't make GRASS a special type of application. There programs or
> set of programs which does not require any special environment (like
> ImageMagic or Graphviz), interpreters or environments (like Python or
> R), and programs with subcommands/subprograms (like docker or svn).
> GRASS should fit into one of there categories. Introducing a special
> type of program just for GRASS and focusing on that will not help users
> and programmers to use GRASS.
>
> In any case, I agree that we need to make things more clear than they
> were so far.
>
> Vaclav
>
> [1] https://lists.osgeo.org/pipermail/grass-user/2015-June/072525.html
>


I think we probably have to agree amongst us before we can make things 
clearer. ;-) Also because I believe that the we see things will 
profoundly effect how we do things in GRASS GIS development.

GRASS GIS was born in a *nix world where, based on the KISS principle, 
toolchains were built out of a collection of small independent programs.

The IT world has significantly evolved and most users today are more 
used to launching integrated applications that do everything "inhouse", 
notably since most interaction today is via GUIs that invite such a 
integration.

GRASS GIS was partly adapted to that world, especially through the 
different generations of GUIs that have created a feeling of 
integration. And the last generation wxgui has even strengthened that by 
integrating more and more specific GUI tools. And your new --exec 
interface creates even more of an integrated application feel.

There still is a user base out there (no idea how large it is) that uses 
the *nix approach and more or less permanently sets up the environment 
that allows the use of GRASS GIS commands just like any other *nix 
command (i.e. r.mapcalc, v.select, etc are equivalent to cp, ls). And 
just because it takes a bit more knowledge to do this, I don't think 
this difficulty warrants discouraging from going down that path, even if 
doing this means that it is your own responsibility to clean up.

I know that you certainly do not want to keep people from using GRASS 
like this, but, as said in the introduction, I'm convinced that by 
seeing (and promoting) GRASS GIS as an integrated application, we will 
slowly but surely start orienting our development along that path as 
well, whenever choices need to made or priorities defined.

I do not know if this is necessarily a bad thing, but I would like it to 
happen at least explicitly, after debate with the development team and 
users.

Moritz