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. 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. 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. On Windows, GISBASE should be set from the registry (with the environment variables allowing this to be overriden, mainly as a developer feature). > > 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. Attempting to side-step the system's execution mechanism will *always* be an incomplete solution. -- Glynn Clements <[email protected]> _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
