On Tue, Feb 4, 2014 at 11:29 AM, Glynn Clements <[email protected]> wrote: > > Markus Metz wrote: > >> Other projects such as gimp or libreoffice are AFAICT reasonably >> bundled with Python, without a Python installer. > > They aren't attempting to support Python scripts as stand-alone > programs (i.e. something which can be run from the command prompt, > batch files, etc).
GRASS scripts, just like GRASS C modules, only run as stand-alone programs if the GRASS environment is set properly and if a valid GRASS session has been established. Thus, GRASS modules do not run from any command prompt, neither from the native Windows command prompt nor from a *NIX shell, without setting the GRASS environment first. Real stand-alone programs are for example the GDAL utilities, but not GRASS modules. > > A compiled program which "embeds" Python (links against the Python > DSO/DLL) to use Python for "internal" scripting is a much simpler > case. And much less useful. Why much less useful? As far as GRASS modules are concerned, users should not be bothered and should not care if a GRASS module is a C module or a shell script or a python script. First of all, a GRASS module must behave like a GRASS module, independent of the language in which it is written. > >> > Most of the troubles arise from attempting to use a mixture of a >> > bundled version and a system-wide installation. >> >> I agree. It seems that the wxGUI always uses the bundled GRASS_PYTHON, >> the reason why the wxGUI works fine without a system-wide Python. > > That was done so that the system Python doesn't need to have wxPython > installed. Note that wxpyimgview does something similar: the top-level > script invokes the wxPython program via GRASS_PYTHON explicitly. Not a good idea, as long as the embedded Python is not always used explicitely. This mixes the embedded Python with any existing system Python which in turn causes the infamous MAXREPEAT error. >> >> Other projects do bundle Python, and there it seems to work just fine. > > They don't merely bundle it, they embed it, which is a much simpler > case. The downside is that Python can only be used within a monolithic > GUI application, which isn't how GRASS works. I disagree. On GRASS 6, the shell interpreter is embedded, and GRASS can be used in a perfectly modular way, e.g. by the Sextante plugin. Wrapping Python scripts in .bat files, just like shell scripts are wrapped in .bat files for GRASS 6, preserves the modular operation of GRASS. > >> I don't understand why we can not also bundle Python, including all >> required Python packages. I meant embed, not bundle. >> >> Otherwise, users would need to install Python, wxPython, numpy, scipy, >> matplotlib, datetime themselves (not sure if the list is correct and >> complete). > > We can facilitate this in most cases. If there isn't already a Python > installation, we can just install the latest 2.x version from the MSI, > and all required packages. If there is a suitable Python installation, > we can leave that and just install any required packages. But after the next upgrade of the system Python, GRASS might no longer be working, and the user is confused. > > The problem only arises when there is an existing installation which > is unsuitable (incompatible version of Python or additional packages). > In that situation, either the user has to make a choice or we need to > figure out how to use the launcher. We should use the embedded Python explicitly to avoid this problem. We were here already. From a user's perspective, the easiest would be if GRASS ignores any system-wide Python installation. Markus M _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
