[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@club.worldonline.be <mailto:mlennert@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