On 25/01/14 16:48, Markus Metz wrote: > On Sat, Jan 25, 2014 at 3:59 PM, Helena Mitasova <[email protected]> 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 > [email protected] > http://lists.osgeo.org/mailman/listinfo/grass-dev > -- Dr. Benjamin Ducke, M.A. {*} Geospatial Consultant {*} GIS Developer [email protected] _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
