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

[Markus Metz]

On Tue, Feb 11, 2014 at 5:39 PM, Glynn Clements
<glynn at gclements.plus.com> wrote:
>
> Markus Metz wrote:
>
>> This is the fundamental difference and the reason why using a
>> system-wide Python can only cause trouble on Windows. On Windows, a
>> software package typically includes everything it needs to run,
>
> On Windows, a software package is typically a monolithic executable
> with no ability to be controlled by other programs (including the
> command interpreter).

Windows users expect software packages typical for Windows.

GRASS is the contrary of a monolithic executable, and should stay so
for various reasons. However, on Windows we need to fake a monolithic
system, because that is how Windows works, if we like it or not.
Having a command interpreter with a GRASS session running on Windows
is IMHO something for power users. On Linux/BSD/Unix, a command
interpreter is started first, then GRASS. On Windows it is the other
way around. The environment established by starting GRASS is (should
be) only valid for the current GRASS session.
>
>> > It's fairly trivial to set a valid GRASS environment globally, so that
>> > commands are usable in any shell. That's how I've had it on Linux
>> > since roughly forever; I don't run the grass70 script unless I'm
>> > testing it.
>>
>> At the very least, GRASS needs to clean up temporary files on exit.
>
> Temporary files need to be cleaned up periodically. The term "on exit"
> doesn't make sense for something which doesn't start or stop.

I thought that is the way GRASS operates currently: a process is
started and stopped when the user types "exit". At least I do that on
Linux when calling grass64 or grass70.
>
>> We use hard-coded special treatment for shell scripts and still they
>> behave like a GRASS module.
>
> Where?

We create .bat wrappers for shell scripts here:
https://trac.osgeo.org/grass/browser/grass/branches/releasebranch_6_4/include/Make/Script.make#L15
>
>> I don't see how users are bothered whether
>> a module is an executable or a shell script. Internally, GRASS can
>> always use system() or subprocess.Popen() for executables and .bat
>> files, but not for shell or Python scripts, Therefore we need
>> hard-coded special treatment for shell and Python scripts in order to
>> make sure that the correct interpreter is used.
>
> IIRC, .bat files were used because there were issues with associating
> .sh with MSys' shell (one of them being that MSys itself doesn't do
> that, so we'd effectively be forced to make global changes to
> something which doesn't "belong" to GRASS).

Msys is not a Windows shell script interpreter. IIUC, msys provides a
minimal, isolated system environment which needs to be started
explicitly.

Just as there were issues with associating .sh with MSys' shell, there
are issues when .py files are associated with the system's Python.
IMHO, any attempt of GRASS to associate .sh files or .py files on
Windows with a particular interpreter is doomed to fail. WinGRASS
includes all the needed interpreters and should use them.

I don't want to defend the way typical Windows software packages work,
but I think it is not worth the trouble to force Unix principles onto
Windows.

Markus M