[GRASS-dev] bug discussion: startup problem with standalone winGRASS install and custom python

Dear GRASS developers,
some 5 months ago I reported the following issue:
http://trac.osgeo.org/grass/ticket/570

It's basically the problem that GRASS won't work on Windows when another Python installation is on the same system (PythonXY in my case).

As Windows compatibility is the target for 6.4 release, please probvide me wth some ideas on how to get rid of the bug.

Thanks in advance,
Timmie

Tim wrote:

Dear GRASS developers,
some 5 months ago I reported the following issue:
http://trac.osgeo.org/grass/ticket/570

It's basically the problem that GRASS won't work on Windows
when another Python installation is on the same system
(PythonXY in my case).

As Windows compatibility is the target for 6.4 release,
please probvide me wth some ideas on how to get rid of the
bug.

the delay is because we simply have no one to work on the
problem.

There are similar problems on Mac, but there we have Michael
and William actively stamping out the brush fires. The byproducts
of that work should make the Windows port easier; ie mis-
assumptions in the code generalised.

I think we need to recruit a python + Windows expert to help
solve the problem. The same is true for the WinGrass wxVdigit
and wxNviz no-run. For those we need someone to get in touch
with the Windows python packaging people and ensure that more
configure information makes it into the next releases(?).
(I'm a bit hazy on that stuff)

so no solutions sorry. the same lack of windows developers means
our whole 6.4.0 release has been delayed a lot, which is
frustrating for everyone. It has been ready to go on Mac and
Linux for months.

regards,
Hamish

Hello Hamish,
thanks for your reply.
Is such a discussion actually welcomed by developers?

> I think we need to recruit a python + Windows expert to help
> solve the problem. The same is true for the WinGrass wxVdigit
> and wxNviz no-run. For those we need someone to get in touch
> with the Windows python packaging people and ensure that more
> configure information makes it into the next releases(?).
> (I'm a bit hazy on that stuff)
I am not an Windows expert but user.
I have grown quite savvy in Python. But I wouldn't like to make a commitment.
Last time is started to fix something in a FOSS project I have seen the lead developer came up with a solution in a faster way... So I felt like having wasted time... I hope you see my point.

Well, may the developers put up a list bugs of Windows showstoppers.
If there is something small among, I may take the issue.
Please comment if you think of a better appraoch.

I offer testing and bugreporting.
But I need to use PythonXY for other purposes and cannot take it off the system.

Thanks & regards,
Timmie

Hello Hamish,
thanks for your reply.
Is such a discussion actually welcomed by developers?

I think we need to recruit a python + Windows expert to help
solve the problem. The same is true for the WinGrass wxVdigit
and wxNviz no-run. For those we need someone to get in touch
with the Windows python packaging people and ensure that more
configure information makes it into the next releases(?).
(I'm a bit hazy on that stuff)

I am not an Windows expert but user.
I have grown quite savvy in Python. But I wouldn't like to make a commitment.
Last time is started to fix something in a FOSS project I have seen the lead developer came up with a solution in a faster way... So I felt like having wasted time... I hope you see my point.

Well, may the developers put up a list bugs of Windows showstoppers.
If there is something small among, I may take the issue.
Please comment if you think of a better appraoch.

I offer testing and bugreporting.
But I need to use PythonXY for other purposes and cannot take it off the system.

Thanks & regards,
Timmie