startup problem with standalone winGRASS install and custom python

[timmie]

please see attachments of error when the program is started with GRASS Icon

[neteler]

See also ​http://trac.osgeo.org/osgeo4w/ticket/82

Please specify the Windows version

[timmie]

• Windows XP
• Python is already installed (PythonXY)

[hamish]

I expect an incompatibility with the PythonXY installation. (ie pyXY is built without some needed library function)

can you install a secondary python install (generic 2.5) to run with grass?

what version of pythonXY? is it supposed to be a full python install + scientific tools, or has it dumped normal python things it thinks a scientist won't use?

from the dos box screenshot it looks like you try with grass 6.4.0rc4.

can you translate the error messages into english for those of us too ignorant to understand?

cheers, Hamish

[timmie]

I expect an incompatibility with the PythonXY installation. (ie pyXY is built without some needed library function)

You may have a look at the standard plugins of PythonXY here: ​http://www.pythonxy.com/standard.php

It's really neat for straight off installation for science.

can you install a secondary python install (generic 2.5) to run with grass?

Just bare Python 2.5? I can try as long as it does not spoil my sys.path More an more FOSS programs have python. On windows, everyone installs its own version of python into the programs directory...

what version of pythonXY?

latest. 2.1.12

is it supposed to be a full python install + scientific tools,

Yes.

or has it dumped normal python things it thinks a scientist won't use?

I don't think so.

from the dos box screenshot it looks like you try with grass 6.4.0rc4.

Yes. from the standalone installer.

can you translate the error messages into english for those of us too ignorant to understand?

I will try: ​https://trac.osgeo.org/grass/attachment/ticket/570/bug_grass.jpg => prozedureinsprungspunkt: starting point of procedure => wurde in der DLL [...] nicht gefunden : was not found in the DLL [...]

​https://trac.osgeo.org/grass/attachment/ticket/570/bug_grass2.jpg => DLL Load failed: Die angegebene Prozedur wurde nicht gefunden : DLL Load failed: the procedure called was not found

Is there a list of python modules that are required for GRASS to run?

[timmie]

I've just seen that GRASS also conatins a menu item for "Old Gui" very good. I would like to see these choices (GUI, OLd GUI, command line) as well in the OSGEO4W install...

I check and GRASS seems to run with the old GUI.

[timmie]

As we suppose that this is a python import error: I would suggest that there are axceptions with error messages added to the points where python needs some distinct modules.

Disclaimer: I never looked at the code of the Python GUI

[cnielsen]

Related errors have been posted elsewhere. The path given in the error "C:\Programs\GIS..." is from my system where I built the installer. Somewhere this path is getting saved even when the installer is supposed to be generic. As I mentioned in other posts, if anyone can tell me how to fix this I will gladly do so, I'm just a packager :).

-Colin

[glynn]

Replying to cnielsen:

Related errors have been posted elsewhere. The path given in the error "C:\Programs\GIS..." is from my system where I built the installer. Somewhere this path is getting saved even when the installer is supposed to be generic. As I mentioned in other posts, if anyone can tell me how to fix this I will gladly do so, I'm just a packager :).

The build process embeds paths in a few files. Specifically, lib/init/Makefile embeds the temporary $GISBASE value in the temporary grass64 and grass64.bat files, and PROJSHARE in etc/Init.sh and etc/Init.bat, while the top-level Makefile embeds the installed $GISBASE value in the installed grass64 and grass64.bat and in etc/monitorcap and etc/fontcap.

The installer will need to fix these paths to point to the actual installed location.

Alternatively, grass64![.bat] could be modified to set [WIN]GISBASE from a registry key (does the installer already set one?). etc/monitorcap isn't relevant on Windows (monitors don't work there). etc/fontcap still needs to be fixed so that the stroke fonts can be found; it would be possible to have the fontcap parser replace a literal $GISBASE with the actual value.

[timmie]

This still persists in <a href="​http://grass.osgeo.org/grass64/binary/mswindows/native/WinGRASS-6.4.0SVN-r36903-1-Setup.exe">WinGRASS-6.4.0SVN-r36903-1-Setup.exe</a>

[hamish]

init.bat has:

set PYTHONPATH=%PYTHONPATH%;%WINGISBASE%\etc\python;%WINGISBASE%\etc\wxpython

maybe if you unset your PYTHONPATH first it will look for just the GRASS version and not the pythonXY version?

or edit grass.bat and remove the '%PYTHONPATH%;' bit at the beginning.

?? Hamish

[neteler]

Timmie,

if you change "Assigned to:" to yourself, then no more email posting to grass-dev happens. Not sure if it is what you want.

Markus

[timmie]

I tried

etc/Init.bat lines 120ff.

::set PYTHONPATH=%PYTHONPATH%;%WINGISBASE%\etc\python;%WINGISBASE%\etc\wxpython set PYTHONPATH=%WINGISBASE%\etc\python;%WINGISBASE%\etc\wxpython

But no success.

there is not %PYTHONPATH% in Grass.bat

[timmie]

If I set in grass64.bat set PYTHONHOME=C:\Programme\pythonxy\python

I get at least the wxpython startup window. After selecting a mapset and pressing enter, the GUI crashes again.

[timmie]

I got it fixed on my computer. It was a problem with the win32 packages for python.

After copying them over from c:\Programme\pythonxy\python\Lib\site-packages\win32\ c:\Programme\pythonxy\python\Lib\site-packages\win32com\ c:\Programme\pythonxy\python\Lib\site-packages\win32comext\

everything works.

The GUI is really nice and fast. congratulations to thos who made it.

Where can upload a ZIP for verification? I would like to know whether this is specific for my setup or others may have the same problem. I can suppose that peaple working a lot with Python may even have 3 python installs: python25, python26, python3000

[timmie]

Since maxium file size was reached I uploaded to: ​http://www.datafilehost.com/download-5ef16604.html

[timmie]

One small issue: When GRASS is started from the menu shortcut, there is still an empty dos CLI in the background.

I think there should somewhere be called pythonw.exe instead of python.exe

But I do not know how to correct this as I do not understand the interactions between Grass64.bat -wxpython and etc/Init.bat

Maybe someone can help here?

[hamish]

timmie wrote:

Where can upload a ZIP for verification?

verification of what? what's in the ZIP file?

One small issue: When GRASS is started from the menu shortcut, there is still an empty dos CLI in the background.

as discussed on grass-dev,

• in the OSGeo4W installer you get a grass terminal session in a dos box using the wx gui
• in the OSGeo4W installer you get a blank dos box when using the tcltk gui until you exit the gui when it becomes a grass terminal session (patch in osgeo4w bug # 83 ​http://trac.osgeo.org/osgeo4w/ticket/83)
• in Colin's stand-alone installer the empty dos box is now minimized by default. maybe some valuable error messages could end up there; maybe Glynn will rewrite grass.bat into a general launch_grass.py.

Hamish

[timmie]

Replying to hamish:

Where can upload a ZIP for verification?

verification of what? what's in the ZIP file?

Yes. I mean, now it works on my computer. But I guess we need to verify if others with different python installations are also affected. Take the contents of the ZIP to compare what has changed.

One small issue: When GRASS is started from the menu shortcut, there is still an empty dos CLI in the background.

Sorry, I should have written: An empty DOS window with no command promp. Just a black window.

• in Colin's stand-alone installer the empty dos box is now minimized by default. maybe some valuable error messages could end up there; maybe Glynn will rewrite grass.bat into a general launch_grass.py.

I think after my replacement of the win32* packages in the GRASS python install, Colins minimisation doesn't work.

[timmie]

Hello, this problem persists on my computer with the latest where PythonXY is installed to the path: C:\python25.

regards, Timmie

[timmie]

The problem still persists with WinGRASS-6.4.0RC5-1-Setup.exe - ​http://grass.osgeo.org/grass64/binary/mswindows/native/WinGRASS-6.4.0RC5-1-Setup.exe

But it appears to be a problem of PythonXY. we are trying to fix it there: ​http://groups.google.com/group/pythonxy/browse_thread/thread/8ccf18a2790a3b56?hl=en

[hamish]

Are the GRASS_PYTHON, PATH, and PYTHON_PATH environment variables all set to pick up a consistent version of modern python? if grass tries to run it's own python.exe but the PATH order grabs the .dll from PythonXY first, it's likely you will see errors.

Hamish

[timmie]

echo %PATH% => points to the PythonXY installation, e.g. C:\Programme\pythonxy\python

echo %PYTHONPATH% => points to my own libraries located elsewhere.

%GRASS_PYTHON% => I thought that this one is set at runtime by GRASS.

I do not know anymore, what to do. I need PythonXY because it delivers what I need for other purposes.

[hamish]

Replying to timmie:

%GRASS_PYTHON% => I thought that this one is set at runtime by GRASS.

If it is working as designed it should respect the value you give for GRASS_PYTHON if it is already set; it should only set automatically if unset.. if you launch grass with ' -text' and type "set" at the command prompt you should be able to see/confirm how it is set.

I do not know anymore, what to do.

I guess you have to use the Tcl/Tk GUI or command prompt until we can figure out the solution. Even if it is still not working we have cleaned up all(?) of the GRASS_PYTHON calls in grass during the course of this bug & so are much closer than we were when we started.

Hamish

[timmie]

Replying to hamish:

Replying to timmie:

%GRASS_PYTHON% => I thought that this one is set at runtime by GRASS.

If it is working as designed it should respect the value you give for GRASS_PYTHON if it is already set; it should only set automatically if unset.. if you launch grass with ' -text' and type "set" at the command prompt you should be able to see/confirm how it is set.

I started GRASS through the Start Menu -> GRASS Command Line

then did: #. enter a location #. set > myvars.txt

in the file myvars.txt GRASS_PYTHON is nowhere to be found.

Even if it is still not working we have cleaned up all(?) of the GRASS_PYTHON calls in grass during the course of this > bug & so are much closer than we were when we started.

Thanks for the positive words and patience you always send across.

I do not know anymore, what to do.

I guess you have to use the Tcl/Tk GUI or command prompt until we can figure out the solution. Even if it is still not working we have cleaned up all(?) of the GRASS_PYTHON calls in grass during the course of this bug & so are much closer than we were when we started.

Hamish

[timmie]

Replying to timmie:

Replying to hamish:

Replying to timmie:

in the file myvars.txt GRASS_PYTHON is nowhere to be found.

Where should GRASS_PYTHON point to?

[hamish]

Replying to timmie:

Where should GRASS_PYTHON point to?

set GRASS_PYTHON=C:\path\to\python.exe

which should be the version of python which you want GRASS to use and set before you try to start GRASS.

make sure the first path with a python25.dll (or whatever that is called) which shows up in your %PATH% matches that.

i.e. the straight-python bits might not care which flavour of python you use as long as the .exe and .dll are matched. But the wxvdigit and wxnviz C++ compiled parts will probably want only the exact python(.exe & .dll) that they were built for.

Hamish

[timmie]

set GRASS_PYTHON=C:\GRASS\extrabin\ C:\GRASS\grass64.bat -text => error

set GRASS_PYTHON=C:\Programme\pythonxy\python\ C:\GRASS\grass64.bat -text

=> error

[hamish]

Replying to timmie:

set GRASS_PYTHON=C:\GRASS\extrabin\

you need the whole thing, including .exe:

set GRASS_PYTHON=C:\GRASS\extrabin\python.exe

C:\GRASS\grass64.bat -text => error

... what does the error say? (can't guess)

Hamish

[timmie]

• entered GRASS_PYTHON='C:\GRASS\extrabin\python.exe' in my environment settings in My Computer.
• C:\GRASS\grass64.bat -wxpython
• I get the error: ​https://trac.osgeo.org/grass/attachment/ticket/570/bug_grass.jpg

Thanks again for your help.

[glynn]

Replying to hamish:

Are the GRASS_PYTHON, PATH, and PYTHON_PATH environment variables all set to pick up a consistent version of modern python? if grass tries to run it's own python.exe but the PATH order grabs the .dll from PythonXY first, it's likely you will see errors.

Can someone explain the point of GRASS_PYTHON, given that running a .py script will use the Python interpreter which is set in the registry?

Absent a reasonable explanation, I intend to remove it in 7.0.

[dvictori]

I had the same problem timmie mentioned, using WinXP, python(x,y) and grass from OSGeo4W. I got it fixed by replacing the pywintypes25.dll in c:/windows/system32 with the one that came with OSGeo4W

[timmie]

so,

• is the pywintypes25.dll from PythonXY wrong?
• who has to solve it: pythonxy or GRASS?

I would like to have them both installed without major problems or negative interaction.

[dvictori]

Replying to timmie:

so,

• is the pywintypes25.dll from PythonXY wrong?
• who has to solve it: pythonxy or GRASS?

I would like to have them both installed without major problems or negative interaction.

I don't know who is at fault. All that I know is that winGrass (OSGeo4W) does not like python(x,y)'s pywintypes25.dll BUT, python(x,y) will work with the file supplied by OSGeo4W. It's probably a python version mix-up problem.

[timmie]

Replying to dvictori: from PythonXY:

One thing is sure: there is no such thing as "Python(x,y)'s pywintypes25.dll" because this DLL is directly coming from the official pywin32 binary package. In other words, installing Python (x,y)'s pywin32 plugin is exactly the same as installing pywin32 official package (​http://sourceforge.net/projects/pywin32/files/ pywin32/pywin32-213.win32-py2.5.exe). And there is more: as you may know, Python(x,y) binaries for Python itself are installed using the official Python .msi installer. So, installing Python 2.5 official distribution with pywin32 official binary package should lead to the exact same bug.

I would suggest to test the previous release of pywin32 (2.12) to see if it's related. And if it is, it's between GRASS and pywin32.

Have you tested a simple Python 2.5 install (with the official binary distribution) with pywin32 2.13?

=> it is an issue between GRASS and pywin32 as it also existed with pywin32 (2.12): I reported this first on 04/26/09 and pywin32 was updated in PythonXY Version 2.1.13 (06-14-2009).

What version of Python and pywin32 is GRASS using?

According to ​http://sourceforge.net/projects/pywin32/ the version2.13 is the mostr recent one!

[timmie]

How can we get a statement from persons packaging GRASS for windows on this Python issue?

[cnielsen]

Replying to timmie:

How can we get a statement from persons packaging GRASS for windows on this Python issue?

Hi Timmie, I'm the packager of the native winGrass but I'm not sure how to deal with your python issue. I use the python package from the OSGeo4W installer so you can check ​here for details on what versions are included there (though I couldn't find details on pywin32). If you think an update of one of those packages would resolve your issue, post to the osgeo4w-dev list. Once that's updated, I'll put out a new native winGrass package with the update as well.

[aghisla]

Replying to dvictori:

I had the same problem timmie mentioned, using WinXP, python(x,y) and grass from OSGeo4W. I got it fixed by replacing the pywintypes25.dll in c:/windows/system32 with the one that came with OSGeo4W

Thanks for the tip dvictori! It solved this issue on my WinXP, OSGeo4W's GRASS (6.4.0svn2) and locally installed Python 2.5 (in C:\Python25\). No need to edit environment variables.

[timmie]

I try to track the Python problem at OSGEO4W: ​http://trac.osgeo.org/osgeo4w/ticket/82

[timmie]

Hi, as stated in ​http://trac.osgeo.org/osgeo4w/ticket/82 This is still an issue with the latest installer.

How can I connect this report with the one in OSGEO4W?

How shall we proceed?

[timmie]

Makred as critical because GRASS 6.4 release aims to support windows correctly.

[timmie]

This problem seems to be fixed in the latest installer:

​http://grass.itc.it/grass64/binary/mswindows/native/WinGRASS-6.4.0svn-r39740-2-Setup.exe (16-11-2009).

Thanks.