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

[Markus Metz]

On Wed, Apr 9, 2014 at 3:44 AM, Glynn Clements <glynn at gclements.plus.com> wrote:
>
> 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.

And this .bat file specifies the script interpreter. Looks like a good
solution to also select the correct Python version.
>
>> > 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.

Other projects also bypass the standard execution mechanism of python
scripts, and they work just fine in MS Windows.

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

I make use of this property daily. On MS Windows, GRASS should by
default behave like a stand-alone application. You can make use of the
collection of command-line modules through the msys shell, but that is
really only for power users.

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

That means creating a new command, a script in the language of choice.
Executing this command and executing GRASS commands are two different
things.

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

As an experienced *NIX user, yes. Not so Windows users, many feel
alienated by a command line. 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.

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

Any installed Python interpreter does not know about any other
packages relying on it. The Python interpreter can change any time
(version, architecture), or disappear, without other packages knowing
about it, then there is a problem. Windows applications are by nature
stand-alone applications, they don't know about each other's
existence.

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

Markus M