Re: [GRASS-dev] Python handling in winGRASS7 [was: Re: GRASS GIS 7 tech-preview release preparations]
On 26/07/13 20:18, Glynn Clements wrote: Moritz Lennert wrote: Would it be a possible option to implement only a) and document the fact that the user has to take care of creating a working Python installation herself if they want b) ? In order to be able to execute scripts via the command prompt, batch files, system(), subprocess.Popen() or similar, the extension must be associated with an interpreter in the registry. This cannot be overridden via environment variables. Note that Python 3 includes a launcher utility for Windows: http://docs.python.org/3/using/windows.html#launcher The idea is that the .py extension can be associated with the launcher, which can be configured to use a specific version of Python in a specific context. I don't know whether it's possible to make use of this without installing the rest of Python 3, though. I just tested the following on a WinXP machine without Python installed (except for the Python in the GRASS installation): - Go to https://bitbucket.org/vinay.sajip/pylauncher - Download launchwin.msi (https://bitbucket.org/vinay.sajip/pylauncher/downloads/launchwin.msi) - Install by double-clicking or with msiexec /i launcher.msi Result: - I can call python modules from the command line (v.db.update, v.db.renamecolumn) - Calling a script from a script works (v.db.renamecolumn) This is without any py.ini, so IIUC just relying on the /usr/bin/env python shebangs in the scripts ! When I installed a 2.7.5 Python from python.org, everything still works the same way, but launching python at the prompt gives me 2.7.5 (i.e. the python.org version, not the GRASS installed version which is 2.7.4), so I suppose that the system-wide installed python is launched, even though its path is at the very end of %PATH%, after grass\extrabin. When I installed a 3.3 version from python.org, running python from the GRASS command line gives me 2.7.4, but running GRASS GUI gives me error messages as does trying to launch v.db.update or other scripts at the command line. The error message contains a reference to python33.dll. Running py -2 gives an error that version 2 is not found. So it seems that the python launcher does not take into account the PATH, PYTHONHOME, and PYTHONPATH settings which all point correctly to the GRASS version of Python, but rather still calls the installed 3.3 version (even it the path to that version is not in PATH). I guess the launcher takes its information from the registry. However, I still think this looks promising as the whole idea of the launcher is to allow multiple instances of Python to run on the same machine. So, maybe it would be enough to figure out how to register the GRASS installation of Python in the registry and then install an .ini in the GRASS7 Application Data directory to direct the python launcher to that version? Moritz ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Python handling in winGRASS7 [was: Re: GRASS GIS 7 tech-preview release preparations]
On 27/07/13 20:08, Glynn Clements wrote: Helmut Kudrnovsky wrote: Python Launcher for Windows is a interesting concept for switching between python versions or for pointing to a specific python interpreter. shebang + py.ini seems to work (see tests in the ticket). IIUC, by this concept a WinGrass-python script would have to be invoked by py.exe (Python Launcher for Windows)? The idea is that you associate the .py extension with py.exe, and it figures out which python.exe to use for a given script. - could this be integrated in WinGrass? Maybe, but it has many of the same issues as any other approach which affects system-wide configuration. - would this help to type only r. in the WinGrass7-windows-console without the .py-extension to start a grass-python-script? Invoking scripts without an extension requires that the extension is present in PATHEXT. Just installing the launcher did the trick for me, even though I did not see anything related to Python in PATHEXT. - would this help to call a python-script within a python-script? - would this help for http://trac.osgeo.org/grass/ticket/2015? The bottom line is that the .py extension has to be associated with a Python interpreter, or something which invokes one (e.g. py.exe). There are multiple valid solutions, and GRASS cannot impose a particular one. But it seems that the launcher is more or less transparent to an existing python installation, i.e. if the user has Python installed (and Python is registered in the registry and the relevant path is in PATH), the launching python on the command line will still call that installed python and double-clicking on a .py file will still launch the file with the installed Python. Only if you use specific shebangs or set up an .ini file, it will call another python. It thus seems the least invasive way of making GRASS use its embedded python. We can then add to the documentation that users need to add a specific shebang to their GRASS python scripts. Another interesting hint concerning the launcher (from [1]): Customised commands allow the launcher to operate as a very flexible shebang line processor, not limited to launching Python scripts. For example, you can launch Perl, Ruby or Haskell scripts using the launcher (as long as the file type associations are set up for the corresponding .pl, .rb and .hs extensions to point to the launcher, and that the launcher’s configuration allows it to map perl, ruby and runhaskell progname values to the paths of the corresponding executables). Of course, those programs already set the registry up to point to their launchers: but using the customisability of the Python launcher, you could (for example) cause ‘perl’ in a shebang line to invoke the Perl interpreter with useful default arguments such as –w (which enables many useful warnings and is recommended). Moritz [1] http://pymolurus.blogspot.be/2012/07/python-launcher-brings-shebang-line.html ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Python handling in winGRASS7 [was: Re: GRASS GIS 7 tech-preview release preparations]
On 29/07/13 18:44, Moritz Lennert wrote: - It thus seems to me that the safest path is the one checking during installation whether a Python 2.7 installation is know in the registry, and if that is not the case, to create a registry entry that points to the GRASS installation Just for the record, I found this from the osgeo4w crew: http://code.google.com/p/maphew/wiki/RegisterPython Not sure if this has made it into osgeo4w directly. Moritz ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Python handling in winGRASS7 [was: Re: GRASS GIS 7 tech-preview release preparations]
On 29/07/13 21:15, Moritz Lennert wrote: On 29/07/13 18:44, Moritz Lennert wrote: - It thus seems to me that the safest path is the one checking during installation whether a Python 2.7 installation is know in the registry, and if that is not the case, to create a registry entry that points to the GRASS installation Just for the record, I found this from the osgeo4w crew: http://code.google.com/p/maphew/wiki/RegisterPython Not sure if this has made it into osgeo4w directly. And to continue in the same vein, trying to find solutions, there is also virtualenv: https://pypi.python.org/pypi/virtualenv + the discussions concerning virtualenv and windows installers: http://nedbatchelder.com/blog/201007/installing_python_packages_from_windows_installers_into.html ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Python handling in winGRASS7 [was: Re: GRASS GIS 7 tech-preview release preparations]
Note that Python 3 includes a launcher utility for Windows: http://docs.python.org/3/using/windows.html#launcher The idea is that the .py extension can be associated with the launcher, which can be configured to use a specific version of Python in a specific context. I don't know whether it's possible to make use of this without installing the rest of Python 3, though. some more test see here: http://trac.osgeo.org/grass/ticket/2015#comment:6 Python Launcher for Windows is a interesting concept for switching between python versions or for pointing to a specific python interpreter. shebang + py.ini seems to work (see tests in the ticket). IIUC, by this concept a WinGrass-python script would have to be invoked by py.exe (Python Launcher for Windows)? - could this be integrated in WinGrass? - would this help to call a python-script within a python-script? - would this help to type only r. in the WinGrass7-windows-console without the .py-extension to start a grass-python-script? - would this help for http://trac.osgeo.org/grass/ticket/2015? - best regards Helmut -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Re-GRASS-GIS-7-tech-preview-release-preparations-tp5066002p5069091.html Sent from the Grass - Dev mailing list archive at Nabble.com. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Python handling in winGRASS7 [was: Re: GRASS GIS 7 tech-preview release preparations]
Helmut Kudrnovsky wrote: Python Launcher for Windows is a interesting concept for switching between python versions or for pointing to a specific python interpreter. shebang + py.ini seems to work (see tests in the ticket). IIUC, by this concept a WinGrass-python script would have to be invoked by py.exe (Python Launcher for Windows)? The idea is that you associate the .py extension with py.exe, and it figures out which python.exe to use for a given script. - could this be integrated in WinGrass? Maybe, but it has many of the same issues as any other approach which affects system-wide configuration. - would this help to type only r. in the WinGrass7-windows-console without the .py-extension to start a grass-python-script? Invoking scripts without an extension requires that the extension is present in PATHEXT. - would this help to call a python-script within a python-script? - would this help for http://trac.osgeo.org/grass/ticket/2015? The bottom line is that the .py extension has to be associated with a Python interpreter, or something which invokes one (e.g. py.exe). There are multiple valid solutions, and GRASS cannot impose a particular one. -- Glynn Clements gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Python handling in winGRASS7 [was: Re: GRASS GIS 7 tech-preview release preparations]
On 26/07/13 00:04, Helmut Kudrnovsky wrote: - One of the issues is whether and how to install Python. As Python is needed both for the wxgui and for scripting, and scripting is something for which you cannot assume an embedded Python interpreter, the preferred solution would be to install Python system-wide using the official Python installer (i.e. possibly having the GRASS installer test for Python installation and if not present, propose to launch the download and execution of the official Python installer). unfortunately and in contrast to Linux/(Mac?), there is 'normally' no 'unique' (system-wide) python 2.x/3.x installation in MS windows OS. windows user software may/may not bring their own embedded/system wide installed python versions. examples for software with embedded python without system wide registry entries: e.g. C:\Program Files (x86)\LibreOffice 4.0\program\python-core-3.3.0 C:\Program Files (x86)\Inkscape\python [...] examples for software with a system wide python installation _and_ with registry entries: e.g. C:\Python26\ArcGIS10.0 C:\Python27\ArcGIS10.1 [...] Yes, and AFAIU, especially via the explanations Glynn gave (notably in [1]), the difference between the two options is whether you want to a) use Python only from within the application, i.e. for internal scripts (IIUC, in GRASS this would translate to scripted modules and the wxGUI), which is the case for Inkscape and LibreOffice or b) use Python also for command line scripting in the general environment and so install Python system wide (e.g. ArcGIS). In the idea that scripts that call GRASS functions should run also when called from outside a running GRASS session, this would be the preferable way for us. However, again IIUC, a) is much easier to implement via an embedded Python interpreter, while b) causes the issues you mention concerning library incompatibilities and the need to install missing necessary Python packages. So the big question is whether we think we can solve the issues related to b) with a reasonable effort. Would it be a possible option to implement only a) and document the fact that the user has to take care of creating a working Python installation herself if they want b) ? Moritz [1] https://trac.osgeo.org/grass/ticket/580#comment:53 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Python handling in winGRASS7 [was: Re: GRASS GIS 7 tech-preview release preparations]
hi, On 26/07/13 00:04, Helmut Kudrnovsky wrote: [...] Would it be a possible option to implement only a) there is already a bundled/embedded python in standalone WinGRASS6/7 and OSGeo4w-WinGRASS6/7. some more issues related to WinGRASS and python are mentioned also in http://trac.osgeo.org/grass/ticket/2015 and document the fact that the user has to take care of creating a working Python installation herself if they want b) ? I would vote for this. Windows users may be less used to prepare their system for their own purposes than Linux users. they are used to get a system out of the box. so a lot of software applications tends to do things all for their own... IMHO it is some kind of operating system design flaw made by MS ;o) which can't be easily solved by an user application. example case: application software X wants to install a system wide python installation in C:\Python27\X and application software Y wants to install a system wide python installation in C:\Python27\Y (I know such cases), both to work properly and both maybe with some slightly modifications to python. but the user wants to work with both applications. who should decide which one is the 'right' system wide python installation? - best regards Helmut -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Re-GRASS-GIS-7-tech-preview-release-preparations-tp5066002p5068898.html Sent from the Grass - Dev mailing list archive at Nabble.com. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Python handling in winGRASS7 [was: Re: GRASS GIS 7 tech-preview release preparations]
On 26/07/13 11:40, Helmut Kudrnovsky wrote: hi, On 26/07/13 00:04, Helmut Kudrnovsky wrote: [...] Would it be a possible option to implement only a) there is already a bundled/embedded python in standalone WinGRASS6/7 and OSGeo4w-WinGRASS6/7. Yes, so this should be reformulated as keep the current option of bundling an embedded python. However, again within the limits of my understanding, aren't the issues of - calling a script from a script and - making addons easily callable linked to the question of system-wide vs embedded Python ? IIUC, in order to solve (at least) the first issue, you have to make python code callable and executable without the .py extension, using assoc .py=Python.File and ftype Python.File=C:\Path\to\pythonw.exe %1 %* but as the ftype setting is system wide, you can't just hijack all python scripts on a machine to use the Python interpreter embedded in GRASS; I'm really not expert enough on these issues, so some input from the gurus would help, here. some more issues related to WinGRASS and python are mentioned also in http://trac.osgeo.org/grass/ticket/2015 I didn't see this yesterday while experimenting with a fresh install on WinXP without system-wide Python installed. I'll try again with a system-wide Python installed to see if that makes any difference. Moritz ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Python handling in winGRASS7 [was: Re: GRASS GIS 7 tech-preview release preparations]
[...] Yes, so this should be reformulated as keep the current option of bundling an embedded python. yes However, again within the limits of my understanding, aren't the issues of - calling a script from a script and - making addons easily callable linked to the question of system-wide vs embedded Python ? #!/usr/bin/env python isn't working in windows, so you need other mechanism to run a python-script with a (specific) python interpreter. http://docs.python.org/2/using/windows.html http://www.python.org/dev/peps/pep-0397/ if python is system wide installed with entries in the registry, then two jobs mentioned above are worked out by the system wide python. if python is not system wide installed with entries in the registry, then you need e.g. a explicit script-invoking by the embedded python interpreter or a file extension association to the embedded python interpreter. at this point calling a script from a script and making addons easily callable comes in with the known issues. nevertheless the wingrass6/7-wxgui itself is working. IIUC, in order to solve (at least) the first issue, you have to make python code callable and executable without the .py extension, using assoc .py=Python.File and ftype Python.File=C:\Path\to\pythonw.exe %1 %* but as the ftype setting is system wide, you can't just hijack all python scripts on a machine to use the Python interpreter embedded in GRASS; that's another quirks and I'm not in favour of it... I'm really not expert enough on these issues, so some input from the gurus would help, here. the same here... some more issues related to WinGRASS and python are mentioned also in http://trac.osgeo.org/grass/ticket/2015 I didn't see this yesterday while experimenting with a fresh install on WinXP without system-wide Python installed. I'll try again with a system-wide Python installed to see if that makes any difference. in my experience - unfortunately - there seems to be also different behaviour between WinXp, WinVista, Win7 and Win8...ggg IMHO the question is/will be: is there a robust mechanism for calling a script from a script and making addons easily callable by the embedded python interpreter working on WinXp, WinVista, Win7 and Win8? if this is working robustely, I think we are on a good way for a nice (python) usable WinGrass6/7... :o) b) use Python also for command line scripting in the general environment and so install Python system wide (e.g. ArcGIS). In the idea that scripts that call GRASS functions should run also when called from outside a running GRASS session, this would be the preferable way for us. this would be a 'nice to have', but IMHO it's more a operating system flaw than a WinGrass-issue ... - best regards Helmut -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Re-GRASS-GIS-7-tech-preview-release-preparations-tp5066002p5068984.html Sent from the Grass - Dev mailing list archive at Nabble.com. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Python handling in winGRASS7 [was: Re: GRASS GIS 7 tech-preview release preparations]
IMHO the question is/will be: is there a robust mechanism for calling a script from a script and making addons easily callable by the embedded python interpreter working on WinXp, WinVista, Win7 and Win8? if this is working robustely, I think we are on a good way for a nice (python) usable WinGrass6/7... :o) maybe there could be some hints to solve this?: Python launcher for Windows http://www.python.org/dev/peps/pep-0397/ Vienna 36°C ... too much tropical conditions here to follow all the infos in this link ... ;o) - best regards Helmut -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Re-GRASS-GIS-7-tech-preview-release-preparations-tp5066002p5068992.html Sent from the Grass - Dev mailing list archive at Nabble.com. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Python handling in winGRASS7 [was: Re: GRASS GIS 7 tech-preview release preparations]
On 26/07/13 17:10, Helmut Kudrnovsky wrote: IMHO the question is/will be: is there a robust mechanism for calling a script from a script and makingaddons easily callable by the embedded python interpreter working on WinXp, WinVista, Win7 and Win8? if this is working robustely, I think we are on a good way for a nice (python) usable WinGrass6/7... :o) maybe there could be some hints to solve this?: Python launcher for Windows http://www.python.org/dev/peps/pep-0397/ This refers to the Python launcher that Glynn mentioned half a year ago: http://lists.osgeo.org/pipermail/grass-dev/2013-January/061466.html The launcher is explained here: http://docs.python.org/3/using/windows.html#launcher It actually allows the use of shebang lines: http://docs.python.org/3/using/windows.html#shebang-lines And it allows to create a py.ini file to customize the way Python is called. A version of that file in the Application data directory overrides systemwide settings, so I guess we could use something like that to customise if shebangs are not enough: http://docs.python.org/3/using/windows.html#customization In my limited understanding this actually sounds like a very promising solution which avoids having to treat Windows in a very different way. shebangs with '/usr/bin/env python' might allow us to solve the issue. Moritz ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Python handling in winGRASS7 [was: Re: GRASS GIS 7 tech-preview release preparations]
Moritz Lennert wrote: Would it be a possible option to implement only a) and document the fact that the user has to take care of creating a working Python installation herself if they want b) ? In order to be able to execute scripts via the command prompt, batch files, system(), subprocess.Popen() or similar, the extension must be associated with an interpreter in the registry. This cannot be overridden via environment variables. Note that Python 3 includes a launcher utility for Windows: http://docs.python.org/3/using/windows.html#launcher The idea is that the .py extension can be associated with the launcher, which can be configured to use a specific version of Python in a specific context. I don't know whether it's possible to make use of this without installing the rest of Python 3, though. -- Glynn Clements gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Python handling in winGRASS7 [was: Re: GRASS GIS 7 tech-preview release preparations]
Note that Python 3 includes a launcher utility for Windows: http://docs.python.org/3/using/windows.html#launcher The idea is that the .py extension can be associated with the launcher, which can be configured to use a specific version of Python in a specific context. I don't know whether it's possible to make use of this without installing the rest of Python 3, though. just a quick test done: - downloaded Python 3.3.2 Windows x86 MSI Installer - Python 3.3.2 extracted but _nothing_ installed (no registry entry) - opened a windows console and change into the extracted folder: cd C:\dl\python-3.3.2\pythonXYZ - C:\dl\python-3.3.2\pythonXYZpy --version Python 2.7.2 it finds the system wide python installation of ArcGIS here on my box - quick script test listed here: http://docs.python.org/3/using/windows.html#from-a-script #! python import sys sys.stdout.write(hello from Python %s\n % (sys.version,)) From the directory in which hello.py lives, execute the command: py hello.py C:\dl\python-3.3.2\pythonXYZpy hello.py hello from Python 2.7.2 (default, Jun 12 2011, 15:08:59) [MSC v.1500 32 bit (Intel)] so for the first quick test it seems it works without installing the rest of Python 3. further testing needed... - best regards Helmut -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Re-GRASS-GIS-7-tech-preview-release-preparations-tp5066002p5069037.html Sent from the Grass - Dev mailing list archive at Nabble.com. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Python handling in winGRASS7 [was: Re: GRASS GIS 7 tech-preview release preparations]
hi Moritz, Is this a correct summary of the issues ? Anything I'm missing ? thanks for the summary, some additions below. On 12/07/13 23:50, Helmut Kudrnovsky wrote: - the python issues in wingrass (notably how to correctly install python to be able to launch scripts and addons) IMHO it's one of the showstoppers in winGRASS7 not only correctly installing python, but also what is the structure/approach in C:\Users\\AppData\Roaming\GRASS7\addons\ of installing python-scripts and bat-wrappers and also related the make-files for addons I'm currently trying to understand all the issues concerning Python in wingrass (I don't think there are any issues concerning Python in GNU/Linux, don't know about Mac). Here's what I've understood so far: - One of the issues is whether and how to install Python. As Python is needed both for the wxgui and for scripting, and scripting is something for which you cannot assume an embedded Python interpreter, the preferred solution would be to install Python system-wide using the official Python installer (i.e. possibly having the GRASS installer test for Python installation and if not present, propose to launch the download and execution of the official Python installer). unfortunately and in contrast to Linux/(Mac?), there is 'normally' no 'unique' (system-wide) python 2.x/3.x installation in MS windows OS. windows user software may/may not bring their own embedded/system wide installed python versions. examples for software with embedded python without system wide registry entries: e.g. C:\Program Files (x86)\LibreOffice 4.0\program\python-core-3.3.0 C:\Program Files (x86)\Inkscape\python [...] examples for software with a system wide python installation _and_ with registry entries: e.g. C:\Python26\ArcGIS10.0 C:\Python27\ArcGIS10.1 [...] if some user software does a system wide installation and registry entries, the py-extension may be registered for this python version. py-extension registered in the MS windows registry may get precedence before a python of the same version embedded in a user software. e.g. here in my Win7-box ArcGIS10.1 does a system wide registry entry for python 2.7 (see above) and therefore the standalone-WinGRASS 7-installer with an embedded python 2.7 doesn't start because of a mismatch of some lib/etc. so the question will be what could a working python installation/python mechanism for standalone WinGRASS/OSGeo4W-WinGRASS be without interefering with other software already using python (systemwide/embedded) in order to avoid the actual quirks This also entails the necessity to download and install the relevant packages (wxPython, numpy, etc). maybe yes/no ... depends of the solution. my ambition would be that all GIS software on my Win7-laptop which using (the same/similar embedded/system wide) python versions are working without interefering ... ;o) - Another issue is how to make it possible in windows to launch modules that are Python scripts by simply calling their module name, without .py extension. At this stage, in a fresh installation of GRASS7 on WinXP, I can launch (and successfully execute) python scripts from the wxGUI menu or the wxGUI command console, but not from the windows terminal. However, calling a script from a script (e.g. v.db.dropcolumn called from v.db.renamecolumn) does not work. yes ... and as described above, not every windows system is 'fresh'... - A third issue, related to the previous IIUC, is how to integrate (i.e. make launchable) script addons. yes ... all logical? ... not always for me ... :o( - best regards Helmut -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Re-GRASS-GIS-7-tech-preview-release-preparations-tp5066002p5068830.html Sent from the Grass - Dev mailing list archive at Nabble.com. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Python handling in winGRASS7 [was: Re: GRASS GIS 7 tech-preview release preparations]
e.g. here in my Win7-box ArcGIS10.1 does a system wide registry entry for python 2.7 (see above) and therefore the standalone-WinGRASS 7-installer with an embedded python 2.7 doesn't start because of a mismatch of some lib/etc. small correction: standalone-WinGRASS 7-installer - standalone-WinGRASS 7-installation - best regards Helmut -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Re-GRASS-GIS-7-tech-preview-release-preparations-tp5066002p5068832.html Sent from the Grass - Dev mailing list archive at Nabble.com. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
