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 _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
