[GRASS-dev] Handling of Python scripts on MS Windows

[Moritz Lennert]

On 11/04/14 13:05, Martin Landa wrote:
> Hi Jurgen,
>
> 2014-04-11 12:42 GMT+02:00 Jürgen E. <jef at norbit.de>:
>
>>> although the architecture may differ, we may get some inspiration for python
>>> windows handling from other GIS projects like QGIS?
>>>
>>> in QGIS python is also in heavy use, e.g. QGIS processing framework, python
>>> addons, integrated python shell, etc. AFAIK they're bundling python in their
>>> standalone winQGIS ...
>>
>> Not sure if I want to participate in this thread.
>
> you are probably not alone...


[...]

 >> That way you could use the stock sources and wouldn't have to use
 >> patches when packaging (which would have been my pragmatic approach
 >> to solve the issue at hand without risking that someone pulls a
 >> Glynn on it ;)).

I don't think this a very helpful attitude. This whole debate is not 
about one bad guy keeping the rest of the good guys from moving forward. 
First of all, Glynn is not alone in his position.

But secondly, and more importantly, the debate is about two fundamental 
questions and these questions need to be debated with patience:

1) Should GRASS be the same (i.e. feature parity) on all platforms ?
2) How much less effort can we ask of Windows users than we ask of users 
of other platforms ?

GRASS was developed in a time when Windows didn't even exist. And it was 
developed in a very typical *nix style and form. This makes for its 
special character and for use forms which are quite different from most 
recent programs. For long years the only way GRASS could be run on 
Windows was by imitating a *nix environment using cygwin.

Growth in interest in free software, accompanied by a continued 
dominance of Windows on the desktop, and the desire of some of us to 
provide the possibility for our colleagues to run GRASS on their Windows 
machines prompted the beginning of a long period of making GRASS 
compilable and runnable natively in Windows. And the switch to Python 
for scripts was, amongst others, motivated by the desire to make these 
scripts more platform-independent.

At no point, however, was there ever the question of creating a special 
Windows version of GRASS, a version that would function differently from 
the *nix version. IIUC, this latter desire seems to have come from 
experiences of some of us with windows users who were not accustomed to 
*nix-style programs/libraries/toolboxes. Thus the debate about whether 
or not we should even show a command line environment outside the GUI 
and thus, now, the argument that GRASS4Win should be a different beast 
than GRASS4NIX in that it should become a monolithic integrated 
application, which, IMHO, fundamentally alters the very nature of what 
GRASS is. Generally, to put it more bluntly, there seems to be an 
attempt to dumb GRASS down for Windows users, who, on average, are less 
computer-savvy than *nix-users (as a side note, this argument is quickly 
losing its grounds when I see the number of GNU/Linux uptakes around me, 
especially now in the wake of the discontinuation of XP-support). The 
idea is that *nix users can solve Python installation issues so as to 
have their system-wide python work with GRASS (to be totally honest life 
is a bit easier for them thanks to the /bin/env solution).

[Side note: The same discussion should also constantly be held about 
functionality which is specific to the GUI, because specifically 
developed for it), i.e. not just a GUI layer above command line 
functionality, something I'm afraid to see creep in more and more...]

Now, as Glynn has pointed out, with distributions soon to ship Python3 
as default (and I'll throw in: with the *nix crowd changing), we will 
quite probably see similar issues in *nix installation as we are seeing 
now in Windows, so the question is how to find a solution which will 
work across all platforms without the need for constant manual 
intervention by developers to solve yet another special case. And, IMHO, 
part of this solution will be through trusting a GRASS user on Windows 
to be capable of following basic instructions concerning the steps to 
follow to install GRASS on their system.

> if you take a look on all threads related to this topic in grass-dev
> ML you will count more that 150 messages, but without real consensus.

Well, there have been different proposals for possible solutions, 
amongst which the Python launcher which I tested last summer [1], but 
except for Helmut, none of those who are pushing for a quick solution of 
the issue seem to have been sufficiently interested to test that path. I 
know I haven't been very active on that front, and so will not throw 
stones, but others shouldn't either...

But whatever the solution, unless we want to turn GRASS4Win into a 
different application than GRASS on other platforms, there will have to 
be a minimal amount of intervention by the user to chose how she wants 
to handle Python on her machine.

To come back to a general note about this debate: As should be clear 
from this and previous interventions, I have my opinion of the direction 
to follow, but I would never claim this to be the one and only. The way 
the debate is being held on the list, does give the impression, though, 
that some think that the solution is obvious and that anyone who opposes 
that solution is just to stubborn/conservative/thick to understand it. 
And that attitude really irritates me.

Moritz

[1] http://lists.osgeo.org/pipermail/grass-dev/2013-July/065197.html