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

[Markus Metz]

On Sat, Jan 25, 2014 at 3:59 PM, Helena Mitasova <hmitaso at ncsu.edu> wrote:
> Just a note, given that most of these problems were caused by conflicts with python installed by ArcGIS,
> I checked with our GIS support and the latest ArcGIS 10.2 installs python2.7 which (I guess) should work with GRASS.

No, there are different versions of Python 2.7, and not all work with
GRASS, see e.g. ticket 2015
>
>
> On Jan 24, 2014, at 3:03 PM, Glynn Clements wrote:
>
>>
>> Markus Metz wrote:
>>
>>>>> Where it gets problematic is if the user already has a Python
>>>>> installation but it's not suitable for whatever reason. In the worst
>>>>> case they may be faced with a choice between using GRASS or using
>>>>> whatever the existing Python was installed for.
>>>>
>>>> IMHO keeping in mind that many GIS-interested winGRASS-users may already
>>>> have been installed other (GIS-)software including a system-wide python
>>>> installation, that will be the demanding challenge to provide a suitable
>>>> solution ...
>>
>> How many users will have versions which are:
>>
>> a) too old for GRASS to use, and
>> b) required to be that old by the existing package?
>>
>> Bear in mind that GRASS won't be the only package affected by an
>> outdated system-wide Python installation.

GRASS should not use a system-wide Python installation, or more
precisely, should explicitly ignore any system-wide python file
associations. Expecting system-wide python file associations is the
cause of all the trouble.

The embedded but not installed Python version coming GRASS works fine
and should IMHO be used for scripts via

@"%GRASS_PYTHON%" "%GISBASE%/scripts/SCRIPT_NAME" %*

>>
>> AFAIK, the primary case where another package requires a system-wide
>> Python installation is ArcGIS, no? IIRC, ArcGIS requires Python 2.6;
>> is there some fundamental reason why this isn't suitable for GRASS? If
>> so, does ArcGIS require that exact version, or can it use a later
>> version?

We can not care for all cases of other software (versions) relying on
a system-wide python installation.
>
> yes, given that most of these problems were caused by conflicts with python installed by ArcGIS,
> I checked with our GIS support and the latest ArcGIS 10.2 installs python2.7 which should work with GRASS
> (correct me if I am wrong).
> We had similar situation with ArcGIS9* and GRASS6.3 where you had to use a specific winpython2.5 build 212
> to have both of them working on the same machine.
> The test suggested by Markus in the related message would be still useful,
> but upgrading to ArcGIS10.2 should solve the problem?

You can hardly suggest users to upgrade ArcGIS if they want to use GRASS...

>
>>> Therefore I would suggest to keep using the embedded Python version
>>> which is known to work
>>
>> Actually, it known not to work, hence this thread.

It works as long as system-wide python file associations are ignored.
Other Python versions might not work.

>>
>> The only way you can make execution of Python scripts seamless (i.e.
>> works with system(), subprocess.Popen(), etc) is for the .py extension
>> to be associated with a suitable interpreter (or launcher) in the
>> registry.

I disagree. For example, shell scripts work just fine in GRASS 6.4,
even though there is no associated suitable interpreter (or launcher)
in the registry.

>>
>> Any other approach will trap us into an endless maintenance burden,
>> identifying cases where we have to provide special handling for Python
>> scripts then implementing that handling.

We did so for shell scripts, AFAIK this works.

Markus M