Glynn Clements 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. > > This is a matter of creating a file and setting some environment > variables. > > It's also not that specific to GRASS. As the Windows filesystem layout > groups files by origin (i.e. .../Program Files/<vendor>/<package>) > rather than by function (.../bin, .../lib, etc), it's fairly typical > to have to at least modify PATH for anything which is meant to be used > from the command line.
This is the fundamental difference and the reason why using a system-wide Python can only cause trouble on Windows. On Windows, a software package typically includes everything it needs to run, embedding any script interpreters, while Linux, Unix, BSD systems use package managers. The fact that ArcGIS installs a system-wide Python is maybe a curiosity coming from the origins of ArcInfo as a Unix application. > > But you can't configure interpreters on a per-process basis on Windows. > You can only do it on Unix because we use the "#!/usr/bin/env python" > hack (which was originally invented to deal with Python being either > in /usr/bin or /usr/local/bin). > >> 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. > > It's fairly trivial to set a valid GRASS environment globally, so that > commands are usable in any shell. That's how I've had it on Linux > since roughly forever; I don't run the grass70 script unless I'm > testing it. At the very least, GRASS needs to clean up temporary files on exit. > > FWIW, I want to make that the default mode of operation. > > I.e. on Unix, set the environment variables in /etc/profile.d/grass7 > or whatever a given distribution uses, so that you only need to > explicitly start GRASS sessions if you want multiple, independent > sessions. I have multiple, independent sessions running pretty much every day. > >> > 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. > > This is my entire point. But that cannot be achieved if you're relying > upon hard-coded special treatment for Python scripts. If Python > scripts cannot simply be executed (via system() or subprocess.Popen() > or whatever) in the same manner as executables or other scripts, the > user will have to be bothered with whether something is an executable > or a Python script. We use hard-coded special treatment for shell scripts and still they behave like a GRASS module. I don't see how users are bothered whether a module is an executable or a shell script. Internally, GRASS can always use system() or subprocess.Popen() for executables and .bat files, but not for shell or Python scripts, Therefore we need hard-coded special treatment for shell and Python scripts in order to make sure that the correct interpreter is used. IMHO, the argument to have GRASS as a GIS processing engine in the background (e.g. for Sextante) that includes everything it needs and does not interfere with other software packages is a pretty strong argument. > > Attempting to side-step the system's execution mechanism will *always* > be an incomplete solution. I disagree because there is no default system execution mechanism for Python scripts: Python is not part of the Windows OS. The recommended Python version as of today would be Python 3.3 64 bit. Markus M _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
