[GRASS-dev] Handling of Python scripts on MS Windows

[Helmut Kudrnovsky]

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.
> 
> 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

please keep in mind that we are providing WinGRASS in different ways (most
used as WinGRASS-standalone and OSGeo4W-WinGRASS; others are QGIS, gvSIGce,
etc) for our users aka community. 

IMHO it would be really a pity to lo lose any of those for our community.

thanks




-----
best regards
Helmut
--
View this message in context: http://osgeo-org.1560.x6.nabble.com/Handling-of-Python-scripts-on-MS-Windows-tp5081335p5102228.html
Sent from the Grass - Dev mailing list archive at Nabble.com.