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

Helmut Kudrnovsky hellik at web.de
Sun Apr 13 15:21:47 PDT 2014


Hi Moritz,

>1) Should GRASS be the same (i.e. feature parity) on all platforms ?

for sure, why not?

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

keep in mind windows and *nix are working as operating
systems sometimes in the same way and sometimes in a (quite) different way.

IMHO the discussion is not/should not be about feature parity etc.; it is
about how to handle/tackle as
software project these differences how operating systems do their job with
monolithic/non-monolithic applications, file extensions associations, global
system variables etc. etc.

> 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 

I don't support to drop the command line in windows and I don't see a reason
why we should do this!

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

see my comments two paragraphs above.

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

I try to outline some scenarios with software using/depending on python in
the windows side ;-) 
of the world which I effectively know in reality:

(a)

software A bundles/embeds python X.x.x
software B bundles/embeds python X.x.x

they can be installed in whatever order

(b)

software A bundles/embeds python X.x.x
software B bundles/embeds python Y.y.y

they can be installed in whatever order

(c)

software A bundles/embeds python X.x.x
software B installs systemwide python X.x.x

they may/may not interfere, depending of file extension associations, global
system variables, 
have the same/different site-packages versions/some missing...

(d)

software A installs system wide python X.x.x
or
software A installs system wide python X.x.y
AND
software B installs system wide python X.x.x
or
software B installs system wide python Y.y.y

...and a lot other variations are already out in the windows world ...

a system wide installation in windows defines the file extension
associations, global system variables, etc.;
additionally the applications need maybe the same site-packages or different
ones (and not always the same versions)

as a system wide installation defines the file extension associations,
global system variables, the installation order A then B or B then A may
break the installation of the other software and so on... 

the *nix environment with their clever package management have clearly some
advantage.

again IMHO the discussion is not about feature parity etc., it is about how
to handle/tackle
these differences how operating systems works ...

I'm pretty sure, if we - the GRASS project - let potential users in the
windows world alone to tackle/handle all these challenges of different
/installations versions etc., we will lose these people ... and this would
be a really pity!!!

my 0.02c€



-----
best regards
Helmut
--
View this message in context: http://osgeo-org.1560.x6.nabble.com/Handling-of-Python-scripts-on-MS-Windows-tp5081335p5134794.html
Sent from the Grass - Dev mailing list archive at Nabble.com.


More information about the grass-dev mailing list