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]
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 Mon, July 29, 2013 16:13, Moritz Lennert wrote: > 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. Continuing my tests. As the details are long, I start with a summary: - If no Python or Python 2.7 is installed system-wide, all issues known to me with Python on Windows are solved by just installing the Python launcher. - If Python 3 is installed system-wide, and no Python 2, then the Python launcher + adding an entry pointing to the GRASS Python installation + python.exe, pythonw.exe and python27.dll copied to the Python27 directory in the GRASS installation also solves all the issues known to me. - Defining a specific grasspython program in the py.ini seems to work if a default Python 2 or no Python installation exists in the registry, but not if Python 3 is the default / only system-wide Python installation. - 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 and then install the Python launcher. Ideally, any other existing Python installation should be made the default in the system-wide py.ini, but that implies that we can create a specific py.ini for GRASS which I haven't been able to do, yet (see details below). * Now in detail: - Python launcher still installed as explained above. - In order to be able to call the GRASS embedded version via the python launcher, I added it to the registry using the script published at [1]. - However, this was not enough as the python installation in GRASS is split over the extrabin, extralib and Python2.7 directory. Even when I added extrabin to the PYTHONPATH defined in the registry, the launcher did find a valid python version. When I copied python.exe and pythonw.exe from extrabin to the Python27 directory, I got an error message about a missing python27.dll. When I copied that from extralib/ to Python27/, I can launch Python from the windows command line by typing py. - After the above manipulations, I can now launch python scripts and scripts called from scripts without using extensions and without conflict with Python 3, even if that is the default version when launching "python" from the windows command prompt. The only things that does not work is launching 'py -3' from the GRASS command line as that call Python 3 but with the GRASS Python environment variables set, leading to incom
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 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]
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 ___ 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]
> > >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\pythonXYZ>py --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\pythonXYZ>py 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]
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 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Python handling in winGRASS7 [was: Re: GRASS GIS 7 tech-preview release preparations]
Moritz Lennert wrote: > - 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. To execute scripts without providing an extension, PATHEXT must include ".PY". -- Glynn Clements ___ 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 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/ 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]
>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]
[...] >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]
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]
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 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]
>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
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
[GRASS-dev] Python handling in winGRASS7 [was: Re: GRASS GIS 7 tech-preview release preparations]
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). This also entails the necessity to download and install the relevant packages (wxPython, numpy, etc). - 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. - A third issue, related to the previous IIUC, is how to integrate (i.e. make launchable) script addons. Is this a correct summary of the issues ? Anything I'm missing ? Moritz ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev