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

[Moritz Lennert]

On 06/10/13 17:05, Martin Landa wrote:
> Hi all,
>
> 2013/10/3 Moritz Lennert<mlennert at club.worldonline.be>:
>>> the question is: is anyone going to resolve this issue? Currently this
>>> is a blocker for many Windows users which we can loose easily if we
>>> don't provide solution soon enough.
>
> that's the point. This issue is open for many months(!). The answer
> for your question is quite predictable. The problem is that we don't
> have a full-time Windows developer. Personally I was forced (by the
> students or my collegues) to try to fix some of Windows bugs in the
> past. If you are forced, usually you invest only a limited time to
> solve the issue. Result is sometimes something like workarounds.
> Better than nothing I would say!
>
>> Users come and users go. I don't think that we have to create unsatisfactory
>
> Huh, I hope you are kidding otherwise I do not understand. Yes, they
> come and go, but we should try to convince them to use our software
> and not to dissuade them from using it.  Please tell me what I can tell
> the students who are attending my classes (they use Windows mostly) or
> to my collegue (hydrologist) who would like to use GRASS in
> comparision to ArcGIS in his research grant. Yes, he is also a Windows
> user. I cannot find a reasonable explanation of this situation what I
> can tell them.

I agree with the frustration, I live it myself, but I don't think that 
we should make people believe that we have solutions when we don't. I 
would love to be able to tell my students to go ahead, use GRASS, it 
"just works" (tm), but there are limitations, and we do not seem to have 
the manpower currently to remove those rapidly. And even if this is 
frustrating, I prefer to say that, and hope that they'll find their way 
back to GRASS once we've had the opportunity to fix the issue.

And it's not as if GRASS is completely unusable on Windows...


> First of all, thanks Vaclav that he found time to take a look at this
> issue.

+1

> His time is limited (as for all of us), the solution is not
> perfect, but it's anyway step towards.

Well, that is the question. According to some, it is a step that takes 
us further away from a real solution. And some quick fixes actually will 
cost us more developer time in the long run.

This does not mean I don't support Vaclav in trying, on the contrary, 
but trying also implies the possibility of error.

> After r57911 we are in the same
> situation. Python scripts called from Python code do not work again!
> It's very serious issue, yes, it's a blocker.

I agree. That's why we haven't been able to release a tech preview, yet. 
But let's take the time it needs to resolve the issue once and for all.

>
> @Glynn: please revert your revert or find a time to implement better solution.

Has anyone actually tried the python launcher as I suggested ? If yes, 
what are your experiences ?

>
> @Moritz: you were discussing tech-previews for many times. Are you
> able to imagine releasing tech-previews with this serious bug. Not me.

I agree.

>> hacks just to get some users now, with the risk of losing them (and others)
>> later when it becomes apparent that the hack doesn't solve everything...
>
> What means "solve everything",

s/doesn't solve everything/only provides a superficial solution which 
contains the risk that it will hit us in the face later, when we've 
already built other parts of the software on top of that solution, only 
making it harder to then roll everything back/

> could you elaborate a little bit? So
> it's better to have broken functionality on Windows for many months?
> It will probably not change within next weeks/months. Good to know,
> it's a nice policy ;-)

As bad as it might sound, but yes, I prefer to have openly broken 
functionality (listing it in known bugs) for the time it takes to find a 
real solution, than to try to put band-aids over it and then move on, 
hoping that the band-aid will stick.

>
>> I think we just have to accept that MS Windows work power is _very_ limited
>> amongst us and that solutions for Windows will take time to be put in place.
>
> Right, that's what I am speaking about.

A solution might be to try to focus resources in the form of a specific 
Windows code sprint, ideally with some Windows power hackers who could 
help us.

BTW, it seems that the same is needed to solve the encoding issues on 
Windows.

Moritz