#580: WinGRASS: $GISBASE/etc/gui/scripts/ require something like $(EXE) to run
---------------------------+------------------------------------------------
Reporter: hamish | Owner:
[hidden email]
Type: defect | Status: new
Priority: blocker | Milestone: 6.4.0
Component: wxGUI | Version: 6.4.0 RCs
Resolution: | Keywords: wingrass
Platform: MSWindows XP | Cpu: Unspecified
---------------------------+------------------------------------------------
Comment (by glynn):
Replying to [comment:6 hamish]:
> > The normal way to associate applications with extensions is via
> > assoc and ftype (but AFAICT, those change the system-wide
> > settings, which may have be overriden by per-user settings).
> ...
> > Note that this will change the registry keys, which will
> > permanently affect the handling of all .py files on the system,
> > not just those which are part of GRASS, and not just for the
> > lifetime of the command prompt.
>
> ... leading to more like bug #570
I thought that #570 related specifically to the GUI.
Note that the GUI is a bit more problematic because it requires a version
of Python with wx 2.8, and relying upon the system Python having this is a
bit optimistic (but not entirely unrealistic; wxPython has stock binary
packages to match the stock Python 2.4, 2.5 and 2.6, and supports
concurrent installation of multiple versions of wxPython).
> So lacking a way to locally set the extension association, our only
choice is to ditch PATHEXT and use wrapper scripts which ensure that the
GRASS_PYTHON enviro var. is respected.
The obvious choice is to simply use the system Python, just like we do on
Unix.
It's not as if the user is overwhelmed by a choice of 20 different third-
party Python packages. There are standard Windows (and MacOSX) binary
packages available from the python.org website (without any of the
licensing issues associated with relying upon !ActiveState, like was the
case for Tcl/Tk).
If the user wants to associate the .py extension with something which
isn't compatible[*] with the stock Python, that's their problem. It's not
like we support Unix systems where /bin/sh is csh, either.
[*] It doesn't have to actually '''be''' the stock Python, but it does
need to provide the same language with the same modules. Scripts don't
need binary compatibility.
> > but any standalone scripts will use the system Python
> > installation, and GRASS shouldn't be interfering with that
>
> is there anything left which won't use the python set by the
GRASS_PYTHON enviro variable? (from #570 apparently the answer is yes)
Running a .py script from the command line or via the Windows shell (i.e.
via !ShellExecute, which includes {{{subprocess.Popen(..., shell =
True)}}}) won't use GRASS_PYTHON, nor should it. Even within a GRASS
session, the command line should be able to run non-GRASS commands,
including those written in Python.
--
Ticket URL: <
https://trac.osgeo.org/grass/ticket/580#comment:8>
GRASS GIS <
http://grass.osgeo.org>
_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev
