Ticket #570 (closed defect: fixed)

Opened 5 years ago

Last modified 4 years ago

startup problem with standalone winGRASS install and custom python

Reported by: timmie Owned by: timmie
Priority: critical Milestone: 6.4.0
Component: Installation Version: svn-develbranch6
Keywords: wingrass, python Cc: grass-dev@…, timmichelsen@…
Platform: MSWindows XP CPU: x86-32

Description

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

Attachments

bug_grass.jpg Download (33.7 KB) - added by timmie 5 years ago.
bug_grass2.jpg Download (58.4 KB) - added by timmie 5 years ago.

Change History

Changed 5 years ago by timmie

Changed 5 years ago by timmie

  Changed 5 years ago by neteler

  • platform changed from Unspecified to MSWindows XP
  • version changed from unspecified to 6.4.0 RCs

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

Please specify the Windows version

  Changed 5 years ago by timmie

* Windows XP * Python is already installed (PythonXY)

  Changed 5 years ago by hamish

  • component changed from default to Installation

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

  Changed 5 years ago by timmie

  • cpu changed from Unspecified to x86-32

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?

  Changed 5 years ago by 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.

  Changed 5 years ago by 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

follow-up: ↓ 8   Changed 5 years ago by 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

in reply to: ↑ 7   Changed 5 years ago by 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.

  Changed 5 years ago by timmie

  • owner changed from grass-dev@… to timmie
  • status changed from new to assigned

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>

  Changed 5 years ago by 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

  Changed 5 years ago by neteler

  • cc grass-dev@… added

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

  Changed 5 years ago by 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

  Changed 5 years ago by 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.

  Changed 5 years ago by timmie

  • status changed from assigned to closed
  • resolution set to fixed

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

  Changed 5 years ago by timmie

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

  Changed 5 years ago by timmie

  • status changed from closed to reopened
  • resolution fixed deleted

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?

follow-up: ↓ 18   Changed 5 years ago by 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

in reply to: ↑ 17   Changed 5 years ago by 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.

  Changed 5 years ago by timmie

  • version changed from 6.4.0 RCs to svn-develbranch6

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

regards, Timmie

  Changed 5 years ago by 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

follow-up: ↓ 31   Changed 5 years ago by 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

  Changed 5 years ago by hamish

  • keywords wingrass, python added

follow-up: ↓ 24   Changed 5 years ago by 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.

in reply to: ↑ 23 ; follow-up: ↓ 25   Changed 5 years ago by 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

in reply to: ↑ 24 ; follow-up: ↓ 26   Changed 5 years ago by 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

in reply to: ↑ 25 ; follow-up: ↓ 27   Changed 5 years ago by 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?

in reply to: ↑ 26   Changed 5 years ago by 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

follow-up: ↓ 29   Changed 5 years ago by 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

in reply to: ↑ 28   Changed 5 years ago by 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

  Changed 5 years ago by 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.

in reply to: ↑ 21   Changed 5 years ago by 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.

follow-up: ↓ 39   Changed 5 years ago by 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

  Changed 5 years ago by hamish

  • summary changed from startup problem with standalone GRASS install to startup problem with standalone winGRASS install and custom python

follow-up: ↓ 35   Changed 5 years ago by 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.

in reply to: ↑ 34 ; follow-up: ↓ 36   Changed 5 years ago by 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.

in reply to: ↑ 35   Changed 5 years ago by 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!

follow-up: ↓ 38   Changed 5 years ago by timmie

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

in reply to: ↑ 37   Changed 5 years ago by 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.

in reply to: ↑ 32   Changed 5 years ago by 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.

  Changed 5 years ago by timmie

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

  Changed 5 years ago by 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?

  Changed 5 years ago by timmie

  • priority changed from normal to critical

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

  Changed 4 years ago by timmie

  • status changed from reopened to closed
  • resolution set to fixed

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.

  Changed 4 years ago by timmie

  • cc timmichelsen@… added
Note: See TracTickets for help on using tickets.