[GRASS-dev] [GRASS GIS] #2424: PyGRASS does not work when GRASS is invoked from outside

GRASS GIS trac at osgeo.org
Tue Sep 16 15:39:17 PDT 2014


#2424: PyGRASS  does not work when GRASS is invoked from outside
------------------------------------------------------+---------------------
 Reporter:  wenzeslaus                                |       Owner:  grass-dev@…              
     Type:  defect                                    |      Status:  new                      
 Priority:  normal                                    |   Milestone:  7.0.0                    
Component:  Python ctypes                             |     Version:  svn-trunk                
 Keywords:  installation, pygrass, temporal, scripts  |    Platform:  MSWindows 8              
      Cpu:  Unspecified                               |  
------------------------------------------------------+---------------------
 When one want to
 [http://grasswiki.osgeo.org/wiki/Working_with_GRASS_without_starting_it_explicitly
 work with GRASS without starting it explicitly], it is possible to use
 `grass.script` but it is not possible to use `grass.pygrass`,
 `grass.temporal` and `grass.lib`.

 This might have been discussed on mailing already, anyway the reason is
 that the dynamic libraries are not accessible to the current process.

 Output on Linux:

 {{{
 Traceback (most recent call last):
   File "./run_grass_from_outside.py", line 62, in <module>
     from grass.pygrass import vector
   File "/opt/src/grass-trunk/dist.x86_64-unknown-linux-
 gnu/etc/python/grass/pygrass/__init__.py", line 7, in <module>
     import grass.lib.gis as _libgis
   File "/opt/src/grass-trunk/dist.x86_64-unknown-linux-
 gnu/etc/python/grass/lib/gis.py", line 23, in <module>
     _libs["grass_gis.7.1.svn"] = load_library("grass_gis.7.1.svn")
   File "/opt/src/grass-trunk/dist.x86_64-unknown-linux-
 gnu/etc/python/grass/lib/ctypes_loader.py", line 55, in load_library
     return self.load(path)
   File "/opt/src/grass-trunk/dist.x86_64-unknown-linux-
 gnu/etc/python/grass/lib/ctypes_loader.py", line 71, in load
     raise ImportError,e
 ImportError: libgrass_datetime.7.1.svn.so: cannot open shared object file:
 No such file or directory
 }}}

 Output on MS Windows:

 {{{
 Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Anaconda\lib\site-
 packages\spyderlib\widgets\externalshell\sitecustomize.py", line 523, in
 runfile
    execfile(filename, namespace)
  File "C:\Users\akratoc\test_grass_standalone.py", line 59, in <module>
    from grass.pygrass import vector
  File "C:\Program Files (x86)\GRASS GIS
 7.0.0beta3\etc\python\grass\pygrass\__init__.py", line 7, in <module>
    import grass.lib.gis as _libgis
  File "C:\Program Files (x86)\GRASS GIS
 7.0.0beta3\etc\python\grass\lib\gis.py", line 23, in <module>
    _libs["grass_gis.7.0.0beta3"] = load_library("grass_gis.7.0.0beta3")
  File "C:\Program Files (x86)\GRASS GIS
 7.0.0beta3\etc\python\grass\lib\ctypes_loader.py", line 55, in
 load_library
    return self.load(path)
  File "C:\Program Files (x86)\GRASS GIS
 7.0.0beta3\etc\python\grass\lib\ctypes_loader.py", line 221, in load
    return _WindowsLibrary(path)
  File "C:\Program Files (x86)\GRASS GIS
 7.0.0beta3\etc\python\grass\lib\ctypes_loader.py", line 207, in _init_
    self.cdll = ctypes.cdll.LoadLibrary(path)
  File "C:\Anaconda\lib\ctypes\__init__.py", line 443, in LoadLibrary
    return self._dlltype(name)
  File "C:\Anaconda\lib\ctypes\__init__.py", line 365, in _init_
    self._handle = _dlopen(self._name, mode)
 WindowsError: [Error 193] %1 is not a valid Win32 application
 }}}

 It is unfortunate that you even cannot import `grass.pygrass.modules`:

 {{{
 from grass.pygrass import modules
 }}}

 For Linux, we have to rely on decision of packagers and a user being able
 to manage `~/.bashrc` or environmental variables of the given process.

 For MS Windows, the solution would be to allow user to add the variables
 to the environment. It seems to me that it is "enough" to add path with
 dynamic libraries (`lib` and `extrabin`) and GRASS installation directory
 (the one with the `grass*.bat` file) to `PATH` and Python packages
 (`etc/python`) to `PYTHONPATH`.

 The solution is of course invasive but there is no other way. A lot of
 applications just do the same without worrying about consequences. We can
 try what Git for MS Windows is doing: giving a choice how git commands and
 other tools should be spread into the system (modify or not modify the
 `PATH`).

 The question of course is what should be the default.

 Other question is whether to add to the beginning or the end of `PATH` and
 `PYTHONPATH` variables.

 Also, there must be a warning (in MS Windows installer) that no other
 version of GRASS GIS will work.

 The same might apply to other OSGeo or related software. This is
 unfortunately unknown. I guess that this option cannot be available in
 OSGeo4W installer.

 I have no idea about Mac OS X. Which solution would be appropriate there?

 Do you have some other ideas how to solve or workaround this issue? Would
 it be possible to provide a script/functionality in GRASS GIS which would
 put the things to environmental variables and take it away if requested (I
 guess that the removal is necessary for standard installation too)? This
 could be much more flexible. This might be even applicable to all
 platforms although for MS Windows it would be quite different from Linux.


 Related:
  * #2333 (choose python interpreter during the GRASS installation on
 windows)

-- 
Ticket URL: <http://trac.osgeo.org/grass/ticket/2424>
GRASS GIS <http://grass.osgeo.org>



More information about the grass-dev mailing list