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

[Markus Metz]

On Wed, Feb 19, 2014 at 3:56 PM, Glynn Clements
<glynn at gclements.plus.com> wrote:
>
> Markus Metz wrote:
>
>> >> > 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.
>
> And I'm suggesting eliminating that mechanism because it's
> inconvenient and unnecessary (at one point, the only way to change
> mapsets was to exit the current session and start a new one, but that
> hasn't been the case for a long while).

Typing "exit" invokes some clean up which I do not want to miss.

We are using something similar to your suggested new mechanism on a
high performance cluster, but struggle with the cleaning up. "We"
means long-term GRASS users and developers. Leaving the cleaning up of
any temp files to the user is IMHO very user-unfriendly.

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

Instead of battling the MS Windows software management system, 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.

Markus M