[GRASS-dev] Handling of Python scripts on MS Windows

[Benjamin Ducke]

Hi All,

On 28/01/14 17:05, Moritz Lennert wrote:
> On 28/01/14 12:07, Markus Metz wrote:
>> On Mon, Jan 27, 2014 at 12:16 AM, Glynn Clements
>>> "Executing" a script uses the registry associations for the script's
>>> extension.
>>

This matters for using os.system("python.exe <script>") from within
a Python script, right?

>> WinGRASS does not set registry associations for Python scripts, nor
>> does it install Python system-wide. This is because we do not want to
>> modify an existing Python installation.
> 

And I think that part should never be changed.

> And that is what is currently causing the issues AFAIU: when calling a
> .py script (or at least when a .py script is called from a .py script)
> the system-wide installation is called and if that is not compatible, we
> have an issue. But as mentioned elsewhere in this thread, it is even
> more complicated because in certain situations is the the GRASS Python
> interpreter which is called, but some of the libraries used are those of
> the system-wide installation.

FWIW, I would start by modifying %PATH% before running os.system(),
so that the bundled python.exe and all of its DLLs are in the Windows
path, preceeding any other folders from which a system-wide Python
could pick them up. Worth a try, I think, before moving on to more
complex solutions. In addition, one should probably never use
os.system("python.exe"), but rather os.system("path-to-bundled-
python\python.exe")

If this helps, it would be straight-forward to replace
all os.system() calls in all existing scripts with a version that
first  sets the path correctly -- and then never use os.system()
directly in a GRASS script.

Another approach would be to have GRASS modify the local registry
settings for the Python shell association, then restore the previous
settings upon exit -- but that would be rather messy.

Best,

Ben

> 
> Out of the current discussion I see the following options:
> 
> - Leave correct system-wide installation to the user and not to the
> GRASS-dev team. This could include some help in form of installation
> check and proposal for installation during WinGRASS install and adequate
> doc.
> 
> - Try to make sure that any call to any Python script in GRASS is done
> via the GRASS Python interpreter (through .bat scripts, with adquate
> GRASS_PYTHON settings, etc). I'm not sure how we can ensure that none of
> the system-wide libraries are called in this case (e.g. MAXREPEAT issue).
> 
> - Creating a virtualenv when installing/launching GRASS and executing
> all Python calls within this virtualenv. AFAIU, this means that those
> who want to combine other Python tools with GRASS either have to install
> them all in that virtualenv.
> 
> - Maybe use the Python launcher, set a specific Python version through
> the launcher and explicitely call that version in GRASS. Again, I don't
> know how well this works with other Python installations (in my small
> experiment I had trouble mixing Python 2 and 3 [1].
> 
> 
> In summary, again within the limits of my understanding, it seems that
> the choices are between
> 
> 1) how much burden we put on the user or not
> 2) how much we want to encapsulate GRASS into an isolated Python
> environment, possibly making interaction with other Python tools on the
> system more difficult.
> 
> All obviously with the additional question of how much dev power we
> can/want to put into this issue.
> 
> I also have to say that I prefer that we take the time to find a good
> solution, despite all the frustration this is creating.
> 
> Moritz
> 
> [1] http://lists.osgeo.org/pipermail/grass-dev/2013-July/065197.html
> _______________________________________________
> grass-dev mailing list
> grass-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev



-- 
Dr. Benjamin Ducke, M.A.
{*} Geospatial Consultant
{*} GIS Developer

  benducke at fastmail.fm