On Wed, Apr 23, 2014 at 1:37 AM, Glynn Clements <gl...@gclements.plus.com> wrote: > > Markus Metz wrote: > >> Therefore it is IMHO not a good idea to rely on a system-wide Python >> file association on MS Windows, > > Regardless of whether or not it's a good idea, it's not entirely > avoidable.
Sure it is. > > If a process "executes" a command using the system's interfaces > (system(), CreateProcess(), subprocess.Popen(), batch files, etc), and > that command refers to a Python script, the registry's .py file > association *will* be used. You ignore my suggestion to use .bat files calling the embedded script interpreter, like in GRASS 6. > >> and therefore I propose to use the >> embedded Python version already coming for some years with the >> WinGRASS installer. > > You can only force the use of a specific Python interpreter when > you control the execution mechanism. Otherwise, the system's file > associations will be used. You ignore my suggestion to use .bat files calling the embedded script interpreter, like in GRASS 6. > > Users who aren't willing to live within whatever walled garden you > provide will have to have a valid system-wide Python installation. In > that situation, that installation should be used always, not just for > those cases where you can't interpose your workaround. You missed the point. I do not want to use a walled garden. Just set the GRASS environment as currently done and off you go (with .bat files, not with .py files). >> >> I suspect the whole discussion boils down to the question whether we >> can rely on GRASS-compatible Python file associations on MS Windows or >> not. I say, we can not. [Your answer here] > > For me, the discussion boils down to: > > 1. How invasive is this workaround going to be with regard to the rest > of GRASS? For using system-wide .py file associations, nobody tried, so nobody knows, thus maximal. > > 2. How easy is it to disable this workaround and just use the system > Python instead?. IMHO an invalid question because an existing Python file association on MS Windows can change or disappear any time, and a GRASS installation will not be notified about this change. > > Batch files are a better solution, as they don't affect anything else, > and it's a simple matter to either delete them or modify PATH to > ignore them, and use the Python scripts directly. Sounds good. Markus M _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev