On 11/04/14 13:05, Martin Landa wrote:
Hi Jurgen,
2014-04-11 12:42 GMT+02:00 Jürgen E. <j...@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
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
