On Sat, Jan 25, 2014 at 3:59 PM, Helena Mitasova <hmit...@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 _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
