[GRASS-user] Error in pansharp tool: missing grass.script

[Vaclav Petras]

On Fri, Jun 26, 2015 at 4:33 AM, Moritz Lennert <
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-user/attachments/20150626/48cf49d6/attachment.html>