Markus Metz wrote: > There seems to be agreement that changing an existing Python file > association is not a good idea.
The problem is that every possible solution has some aspect which is "not a good idea". > 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. Note that the same is also true of the .bat file association. On Unix, "python" may change from 2.x to 3.x. There is a limit to how far we can (or should) go to protect against defects in the underlying platform. Every workaround has an associated cost. > 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. 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. > 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. 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. > With .bat file wrappers, you would not even need to set a particular > python environment, it would just work. Just as on any other OS, all > GRASS commands would be available after running the grassxy command. > If, as Glynn suggests, running grassxy should not be required, instead > the GRASS environment is set permanently at login time, there would be > no difference, except that you don't need to bother about funny > (non-)existing Python file associations on MS Windows. > > 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. For me, the discussion boils down to: 1. How invasive is this workaround going to be with regard to the rest of GRASS? 2. How easy is it to disable this workaround and just use the system Python instead?. IMHO, "solutions" such as making run_command() detect Python scripts and apply special treatment are non-starters on both fronts. 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. -- Glynn Clements <[email protected]> _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
