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

Glynn Clements glynn at gclements.plus.com
Fri Jan 24 12:03:05 PST 2014


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?

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


More information about the grass-dev mailing list