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

Sun Apr 13 09:52:07 PDT 2014

On 13/04/14 17:03, Moritz Lennert wrote:

[...]

> 
> 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.
> 

I agree. I tend to take a conservative view, because I am
old enough to have seen several trendy technologies and programming
styles come and go. I think that GRASS has done very well and
acquired an excellent reputation exactly because it has not
compromised on its cleanly engineered architecture.

> 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 ?

I would say: Yes. I'd be a big step backward if users would
be tied to a certain operating system to get their work done.

> 2) How much less effort can we ask of Windows users than we ask of users
> of other platforms ?

We can ask them to put in just as much effort as everybody else.
I do think that most GRASS users on Windows don't mind, actually.
However, this is not true when it comes to running GRASS from
a host GIS such as QGIS (see my comments below).

> 
> 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...]
> 

Agreed. Once more, I plead for a clean separation between GUI
and CLI developments, and a disconnection of their release cycles.
The wxPython GUI can be considered a monolithic application,
and FWIW it can pull every trick in the book to integrate a
Python interpreter, and to make it all easier for Windows users.

But please: Let's keep (minor) version-specific Python support
and all of its associated problems out of the core release.

I really believe that this whole conundrum was caused by not
taking that step earlier.

> 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.
> 

I would say: Consider the wxGUI, the QGIS and gvSIG plug-ins etc.
monolithic applications and let their maintainers figure out how
to deal with this. In the gvSIG CE project, we do a lot of hair-
raising stuff to hide the complexity of GRASS and its dependencies
from the end user, and I suspect so does QGIS. But I would not
advocate the same approach to the core GRASS architecture.

>> 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...
> 

Just to re-iterate my main point: By now I think that such "solutions"
(or rather work-arounds) are perfectly acceptable for QGIS or gvSIG CE,
which are less flexible and more controlled environments than CLI
GRASS by design, anyway. We will certainly explore these options for
gvSIG CE, but I have come to think they are futile efforts for core
GRASS.

> 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.
> 

I think some intervention is perfectly acceptable. This is already
required from all those (Windows) users that want to install proprietary
format support, such as ECW or MrSID on their machines, due to choices
they have to make re. licensing terms. On Windows, this can all be
handled in a unified way by the OSGeo4W installer.

> 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.
> 

Yes, there is some cause of irritation. But this discussion is still
important and has produced some really good insights. So I think we
should all take a deep breath and carry on, as exhausting as it may be.
These are important directional decisions and they should not be rushed.

Cheers,

Ben

> Moritz
> 
> [1] http://lists.osgeo.org/pipermail/grass-dev/2013-July/065197.html
> _______________________________________________
> grass-dev mailing list
> grass-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev

-- 
Dr. Benjamin Ducke, M.A.
{*} Geospatial Consultant
{*} GIS Developer

  benducke at fastmail.fm