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

[Moritz Lennert]

On 14/04/14 00:21, Helmut Kudrnovsky wrote:
> Hi Moritz,
>
>> 1) Should GRASS be the same (i.e. feature parity) on all platforms ?
>
> for sure, why not?

Not to single out MarkusM, but just since he formulated it so clearly:

 >On 09/04/14 08:16, Markus Metz wrote:
 >> On Windows, GRASS should behave like a
 >> self-contained GUI application. There were even suggestions to remove
 >> the command line interface completely from winGRASS because it
 >> confuses users.

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


So, there is a vision by some that for the reasons of apparent 
"incompatibility" between the way GRASS works and Windows, GRASS has to 
be different on windows. I.e. that GRASS has to become a monolithic 
application on Windows.

I also think that some of the debate comes from the question of whether 
the wxGUI should have a special status or whether it should just be 
treated as one of the hundreds of modules that GRASS offers.


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

[snip]

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

As has been mentioned often enough: there is a big difference between 
types of software, between monolithic GUI applications and others.

And AFAIK, no one has suggested that the GRASS installer should just 
install Python system-wide, but rather that a correct Python 
installation would be left to the user, with possible help in the 
installer (e.g. suggesting installation if it detects no installation at 
all, clear documentation on different cases, etc).

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

There is quite a large margin between creating a monolithic application 
with everything bundled and leaving the user alone...

To answer Martin's call for concrete action: how difficult would it be 
for you, Helmut, to create a GRASS installer without Python, so that we 
can test that scenario ? I don't have the Windows build toolchain set up 
at the moment, but if it's more work for you than a few lines of code to 
change and command to create a new package, then I'll try to find the 
time to do that.

Moritz