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

[Benjamin Ducke]

On 25/01/14 16:48, Markus Metz wrote:
> 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.
>>>>>

There is a tool called "Virtualenv" that seems to address exactly
this problem: https://pypi.python.org/pypi/virtualenv

See also here: http://docs.python-guide.org/en/latest/starting/install/win/

I found it via this thread:
http://stackoverflow.com/questions/1108974/switch-versions-of-python

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

I don't know in how far a pre-existing system installation of
Python would interfere with Virtualenv or similar solutions.

But I hope that the above could be a useful approach to
solving this problem.

Best,

Ben

>>>
>>> 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
> _______________________________________________
> grass-dev mailing list
> grass-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
> 



-- 
Dr. Benjamin Ducke, M.A.
{*} Geospatial Consultant
{*} GIS Developer

  benducke at fastmail.fm