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

[Markus Metz]

I do not understand this ongoing discussion on WinGRASS7+Python. My
proposed solution caters for all possibilities, in particular:

- an existing incompatible .py file assocation
[add your workaround here]

- changes in any existing .py file association after GRASS has been installed
[add your check-at-startup-mechanism here]

Moritz Lennert:
> Markus Metz:
>>
>> [...] An existing system Python on MS Windows can change or disappear
>> any time, and a GRASS installation will not be notified about this
>> change.
>
> But that's exactly the same on any OS, including GNU/Linux. It is up to the
> user/sysadmin/packagers to ensure that Python is installed. But I can
> uninstall Python at any time on my system and GRASS will never be notified.

On GNU/Linux|*BSD|UNIX, this would be a packaging error. Python must
be a dependency for GRASS7. The package manager will take care of it.
As long as you have installed GRASS using the system's package manager
(who takes the hand of the user and takes care of everything).

Glynn Clements wrote:
>
> Markus Metz wrote:
>> [...] an existing system Python on MS Windows can change or disappear
>> any time, and a GRASS installation will not be notified about this
>> change.
>
> Yes; and your point is?

GRASS has to check each time it is started if a compatible system-wide
.py file association is available. This is IMHO nonsense.

As long as you do not provide this test, I will revert any change that
enforces the use of system-wide .py file assocations.

>
> If my system Python were to suddenly change or disappear, I'd be far
> more concerned about "who did that, and how?" than about GRASS not
> working.

Ask your sysadmin.

Anyway, there are four valid Python installations for MS Windows:
- Python 3 64 bit
- Python 3 32 bit
- Python 2 64 bit
- Python 2 32 bit

IMHO, we can not wait until all these versions are supported by the
same GRASS7 wingrass installer.

>> 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.
>
> 1. GRASS_PYTHON is just a pathname (it needs to be quoted in the batch
> file because it may contain spaces), while the registry entry can
> specify switches. This could be worked around by setting GRASS_PYTHON
> to a batch file, but ...

In this case GRASS_PYTHON must be a path name, something like asking
the user to select one of several possibilities.
>
> 2. Batch files just add another source of potential problems. E.g.
> anything beyond the simplest cases fails on non-ASCII data (more
> precisely, whenever you use bytes which don't have identical
> interpretations in the "ANSI" and "OEM" codepages).
>
> Personally, I'd rather just execute the scripts directly, as is done
> on Unix.

Huh?

On MS Windows, .exe and .bat files are executed directly, but not .py
files. Any .py files are not executed on MS Windows, they are an
argument to the .py file's registry association. Ideally, .py files
are an argument to the system-wide Python Installation, whichever that
will be, but probably (75%) not compatible. The default .py file
association can also be a text editor wchich makes perfect sense
(probably not only) on MS Windows.

Also on *NIX systems, the scripts are not executed directly, instead
the shebang "#!/usr/bin/env python" is used which could be changed to
"#!/usr/bin/env python2" as long as GRASS7 does not comply with
Python3.

>
>> 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.
>
> ESRI don't appear to be concerned about this "problem", and their
> users are paying them (rather heavily, I might add). And they don't
> even have to consider portability; it's Windows-only.

ESRI assumes that their system-wide Python installation will never
change. That is rather ignorant. I don't think GRASS should mimik the
aggnorant ignorance of ESRI.

>
> We're not even demanding that our users use a specific Python package,

Yes we do. At the moment we require the same Python 2.x 32 bit version
that is embedded in OSGEO4W and the standalone WinGRASS installer.
Remember, we are taking about the status quo.

Markus M