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

[Glynn Clements]

Markus Metz wrote:

> > All of this goes out the window if you want to provide a command-line
> > environment, whether an interactive shell or the ability to execute
> > commands via system() or CreateProcess().
> 
> It works in GRASS 6 with shell scripts. I am sure the same mechanism
> will work just as well with python scripts.

GRASS 6 creates a .bat file for each shell script.

> > The only way that you can "configure" Windows' command execution
> > mechanism is by registering extensions.
> 
> I suggest to not even attempt to configure a Windows' command
> execution mechanism.

If you mean "don't mess with the existing .py association", I agree
with you. If you mean "make every attempt to bypass the standard
execution mechanisms", that will make WinGRASS a second-rate imitation
of the Unix version.

In spite of wxGUI, GRASS remains fundamentally a collection of
command-line modules, more like a library than an application.

The big advantage of this is that that it can be scripted, in any
language capable of executing commands. Python, Bourne Shell, cmd.exe,
Visual Basic, or whatever.

You can either attempt to "capture" and bypass as many of the possible
interfaces to the system's execution mechanism as possible, or you can
make the system's execution mechanism work.

The latter one requires dealing with factors beyond our control, but
ultimately it results in a superior product (it's also less work).

> >> Instead of battling the MS Windows software management system,
> >
> > But that's exactly what trying to "bundle" Python is doing. You don't
> > trust the OS to be configured correctly so you're trying to construct
> > an isolated sandbox.
> 
> Exactly! E.g. LibreOffice and Gimp also operate as isolated sandboxes.
> Actually, pretty much every MS Windows software is an isolated
> sandbox. This is the safest way to ensure proper operation on MS
> Windows.

These are self-contained GUI applications. Which is a major
limitation; if I need to manipulate images, I'm more likely to use
NetPBM or PIL/NumPy than GIMP (on any platform). Apart from anything
else, the job will be over and done while GIMP would still be showing
the splash screen.

If I'm likely to perform the same operation more than once, I'm *much*
more likely to use the scripted approach than the pointy-clicky GUI.

> IMHO, what you say is that GRASS and MS Windows are incompatible by
> principle,

Not at all. Windows does actually have a command-execution mechanism
(even the Mac has one nowadays).

Some people even run web servers on Windows (and I don't believe that
Microsoft has yet found a way to use arbitrary GUI programs in place
of PHP, ASP or whatever).

> and you will not succeed in making MS Windows compatible
> with these GRASS principles. I assume WinGRASS users expect a typical
> MS Windows software like clicking on the GRASS icon which executes a
> command (grassXY) and starts the software. I strongly suggest to
> respect the users' expectations. It does not matter in this respect if
> the command actually only sets the environment for GRASS modules and
> if this environment is like a sandbox or system-wide. FWIW, Linux
> users also execute a grassxy command to start GRASS.

No matter how much GUI you wrap around it, GRASS is never going to be
a "point-and-drool" application aimed at users who want a "Solve my
problem for me" icon on the toolbar.

I would expect anything beyond the simplest cases to be scripted. So
that you can easily repeat the exact process with next month's data,
or with a different value for a parameter, or so that you can easily
communicate your methodology to others (I find pasting a script
fragment somewhat easier than "... then click on the icon that looks
like, uh, ...").

-- 
Glynn Clements <glynn at gclements.plus.com>