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 <gl...@gclements.plus.com> _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev