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

[Helena Mitasova]

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.


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

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?

Helena



>> 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.
> 
> 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.
> 
> 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.
> 
> -- 
> Glynn Clements <glynn at gclements.plus.com>
> _______________________________________________
> grass-dev mailing list
> grass-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev