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

Glynn Clements glynn at gclements.plus.com
Wed Apr 9 09:22:21 PDT 2014


Vaclav Petras wrote:

> > And this .bat file specifies the script interpreter. Looks like a good
> > solution to also select the correct Python version.
> 
> 
> I'm afraid how will work for user scripts. Typical case will be that user
> has some Python, so he or she will try to run from outside if he or she
> sets the environment correctly, running of modules (exe or bat) will be OK,
> but grass.pygrass and grass.lib might not be OK.
> 
> The other typical case (hopefully more common) is when a user writes his or
> her own GRASS Python module/script. This does not contain any environment
> settings (same as .py in scripts/ and temporal/) because it is intended to
> be run inside of GRASS session. However, it will not run because there is
> no .bat. Should user create one? Should GUI do some workaround for that
> case? But what about Python command line, wxGUI command console and
> standard Windows command line?
> 
> My point is that nobody was writing shell scripts on Windows but people are
> writing Python scripts/modules. So, this new problem to solve.

My view is that .bat files may have some value as a workaround to make
GRASS mostly functional on systems which lack a usable (or any) Python
installation. A significant advantage is that they're a lot less
invasive than having hard-coded treatment for Python scripts littered
throughout GRASS.

On systems with a suitable Python installation, neither .bat files nor
the use of a bundled Python interpreter should be forced upon the
user.

My main criterion for any workaround for Python-on-Windows "issues" is
"First, do no harm". Users who want feature-parity with Unix (and are
willing to satisfy the requirement of having Python as a "system
feature") shouldn't have to suffer in order to make the packager's job
easier.

-- 
Glynn Clements <glynn at gclements.plus.com>


More information about the grass-dev mailing list