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. _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev