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

[Markus Metz]

On Fri, Apr 25, 2014 at 5:18 AM, Glynn Clements
<glynn at gclements.plus.com> wrote:
>
> Martin Landa wrote:
>
>> It's easier to check if the file is a python script and if so than
>> to force to use bundled version of Python.
>
> So long as I have commit access, GRASS isn't going to be "forcing" the
> use of a non-system Python.

But an existing system Python on MS Windows can change or disappear
any time, and a GRASS installation will not be notified about this
change.

I am not opposed to using the system's Python, I just don't trust it.
>
> By all means provide fall-backs, workarounds, alternatives, or
> whatever, but anything which tries to make such things mandatory is
> going to get reverted. Again.

How about ignoring .py file associations and set GRASS_PYTHON to the
system's Python? If that does not work or disappeared, make
GRASS_PYTHON fall back to the embedded version? IOW, always use
GRASS_PYTHON, but let GRASS_PYTHON be the system's Python if possible.

The downside is, GRASS would need a new mechanism to test if python
scripts can be executed on the current system. This mechanism would
need to be run before any GRASS modules. We would also need clear
messages to users about any problems and how these problems can be
resolved. Further on, any solution should not require administrative
privileges.

Anyway, IMHO we really must have a mechanism to avoid the system's .py
associations because an existing Python file association on MS Windows
can change or disappear any time, and a GRASS installation will not be
notified about this change.

>
> Batch files aren't a problem, as they can just be deleted or the
> directory removed from PATH.

Sure, the idea is to have any wrappers in one directory and the actual
python scripts in another directory. Then it is just a matter of
setting PATH accordingly: hide the one directory, include the other
directory. run_command() etc can stay as they are right now.

Markus M