#841: python script modules should use pythonw on OSX; they also ignore GRASS_PYTHON --------------------------+------------------------------------------------- Reporter: kyngchaos | Owner: [email protected] Type: defect | Status: new Priority: normal | Milestone: 6.5.0 Component: default | Version: unspecified Resolution: | Keywords: Platform: Unspecified | Cpu: Unspecified --------------------------+------------------------------------------------- Comment (by glynn):
Replying to [comment:2 kyngchaos]: > > Most 7.x scripts don't use wxPython directly. They might use it indirectly via g.parser, but that should be dealt with by $GRASS_PYTHON. > > OK. I was going by the new v.krige in 6.5, where I noticed the problem. So, the g.parser stuff happens in a completely separate process? Yes. > What I saw in one module I looked at is that the script loads the grass module, then runs grass.parser(), then runs the main script. No chance for it to run anything with GRASS_PYTHON. grass.parser() runs g.parser, which calls G_parser(); if arguments are required but not provided (or if the --ui switch is given), this will run menuform.py via $GRASS_PYTHON (module_gui_wx() in lib/gis/parser.c). Eventually, g.parser will return the option/flag values back to the script, which doesn't care whether g.parser got the values from the command line or from a GUI dialog. > > AFAICT, most scripts should be using "python", not "pythonw" > > Except when they use wx, like v.krige. Most scripts shouldn't be using wx. In fact, we may want a completely separate directory for this. IMHO, anything in the scripts directory should behave like a normal GRASS module (parse command line, perform processing, terminate). Applications are something else, even if they're written in Python. > >> Though, I see another potential problem with the #! -- it completely ignores GRASS_PYTHON, > > That shouldn't be a problem. > > How is that not a problem? Say there are 2 pythons in the PATH (or another not in the PATH) and I don't want to use the first one, so I set GRASS_PYTHON to the full path to the other. But then /usr/bin/env python[w] goes and runs the first one anyways. That's already the case for every other Python script on your system (and similarly for /bin/sh etc). GRASS_PYTHON exists as a workaround for the case where the system Python cannot be used. AFAICT, the primary use case is where binary GRASS packages bundle a version of Python because that's the only way that we can ensure compatibility with extensions such as vdigit and nviz. In any case, you can't use environment variables within the #! line (which is ignored on Windows anyhow). No other project seems to consider this a problem (not just for Python, but for any interpreted language). -- Ticket URL: <https://trac.osgeo.org/grass/ticket/841#comment:7> GRASS GIS <http://grass.osgeo.org>
_______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
