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

[Markus Metz]

On Thu, Mar 6, 2014 at 10:08 AM, Glynn Clements
<glynn at gclements.plus.com> wrote:
>
> Markus Metz wrote:
>
>> > .py is supposed to be associated with a Python interpreter, and
>> > the stock Python installer will do that.
>>
>> .py is not supposed to be associated with a Python interpreter that is
>> installed system-wide
>
> It certainly is, because that's what the stock Python installer will
> do by default.

I was unclear, I mean that any .py association must be ignored because
GRASS might be might be incompatible with the stock Python installer .

>
>> because this assumes some kind of package
>> manager as available on Linux/BSD/Unix. MS Windows does not have a
>> package manager. Any software installed on Windows must include any
>> script interpreters and enforce the use of these for the respective
>> scripts.
>>
>> The fundamental assumption of MS Windows software installers is that
>> no other software installer will interfere with its installation. This
>> assumption is violated as soon as a software installer invokes another
>> software installer. This means that the WinGRASS software installer
>> should not invoke or require a Python installation on MS Windows.
>
> 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.
>
> 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.
>
>> 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.

>
>> I would
>> rather follow the approach of other projects that have been running
>> successfully on MS Windows with their embedded python interpreter for
>> a couple of years.
>
> You're referring to monolithic applications which require that any
> "scripting" is done from within the application itself. They typically
> also require the use of a specific language for scripting, and have
> entirely separate mechanisms for extension via scripts and extension
> via compiled code (the latter typically being in the form of DLL
> "plug-ins").
>
> IOW, the exact opposite of GRASS.

IMHO, what you say is that GRASS and MS Windows are incompatible by
principle, 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.

Markus M