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

[Moritz Lennert]

Martin,

On 18/01/14 10:36, Martin Landa wrote:

> Unfortunately nothing really changed as I noted 3 months ago. I am
> using GRASS 7 at the university for teaching GIS and remote sensing.
> During winter semester students started to report bugs related to this
> issue. I was thinking how I can explain them why it's still broken or
> better to say we are still keeping it broken. My patience is now at an
> end, students couldn't simply solved final tasks to finish the course.
>
> There are many places where a python script is called from a python
> code (eg. `g.extension` from wxGUI wrapper, `r.mask` in different
> python scripts or `v.db.addtable` in `g.gui.iclass` when exporting
> training areas). Many more functionality is simply not working on
> Windows.
>
> I hoped that I will be not forced to do that, anyway the daily builds
> of G7 [1] now contains Vaclav's workaround introduced in r57910. I
> expect that such commit would be immediately reverted without
> providing any better solution (as in October). Keep it simply broken
> we don't care about our software whether is functional. It's our
> message to the users which I was not able to say to the students. I
> want to attract them to use open source and not to disgust them.

Being confronted with the same issues with my students, I understand 
your frustration. And I wish a solution could be found.

The big question, as always, is how far do we want to go in doing things 
for the users, and how much can we ask users to do themselves. The 
general gist normally is that Windows users are computer illiterates and 
that we should, therefore, prepare everything for them. This however 
implies that _we_ have to find a solution to all problems this entails.

Another option would be to do what Glynn has been proposing all along 
(IIUC), which is to not install Python with Wingrass, but rather leave 
it up to the user to make sure a suitable Python is installed in the 
path. I personally would plead for the latter, as I think that someone 
who can handle GRASS should be able to follow some instructions 
concerning Python handling and as experience has shown that our team is 
too small to do everything for the user.

In my few tests, I had fairly good results with the Python launcher, but 
this was with the GRASS Python installation [1]. Everything "just 
worked", without any of the hacks proposed since then.

I don't know how hardcoded the existence of a GRASS Python installation 
is and how hard it would be to create an installer without Python in 
order to test different solution in that direction.

Maybe we could try to organize a "virtual sprint" where we all decide of 
a day and time for which we all prepare windows machines so that we can 
try to concentrate on this, major, issue and hopefully solve it "once 
and for all".

But we also need to answer the fundamental question on how far we should 
go in doing things for Windows users, instead of showing them the way to 
do it themselves.

Moritz

[1] http://lists.osgeo.org/pipermail/grass-dev/2013-July/065197.html