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

[GRASS GIS]

#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                               |  
------------------------------------------------------+---------------------

Comment(by zarch):

 Replying to [comment:2 wenzeslaus]:
 > Another case when I'm hitting this issue is in running tests.
 > There is a script which runs the tests. I import form gunittest
 > in this test and I don't really need much but in __init__.py
 > I import some things to provide and easy access, so whatever
 > I want to import, __init__.py gets executed, because pygrass.modules
 > are used this executes the pygrass main __init__.py which imports
 > some PyGRASS things which depend on ctypes interface and when
 > dynamic libraries are not available, this obviously fails.
 > This is an example, how simple you may need dynamic libraries.
 > Temporal framework Python API is probably the same case.

 Since the pygrass.modules does not depend from the ctypes, I think we
 could move the modules stuff outside pygrass to remove the depedencies to
 ctypes...

 The main problem is that I put in pygrass.__init__:

 {{{
 import grass.lib.gis as _libgis
 _libgis.G_gisinit('')
 }}}

 Because all the pygrass sub-modules: gis, raster, vector and functions
 must have G_gisinit,
 If you think that move the pygrass.modules outside pyrass is not a good
 idea, I can move the G_gisinit from the main __init__ of pygrass to the
 sub-modules.


 > Another way how to improve the situation is to use
 > empty __init__.py files.

 Generally I'm not against to an empty or almost empty init file.
 So If you agree on that, I could change it.

 This it will change the way as we import stuff, so it wont be possible to
 import:

 {{{
 from grass import pygrass

 # and then access to the sub-modules
 pygrass.modules.Module
 }}}

 For me it is not a problem, generally I import the class that I need on
 the top, like:

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

 In any case I think that the pygrass.modules.__init__ should contain at
 least:

 {{{
 from grass.pygrass.modules.interface.module import Module,
 ParallelModuleQueue
 }}}

 just to make the use of these classes more convenient and to "hide" the
 internal structure:

 {{{
 modules/
   interface/
     module.py
     ...
 }}}

 Otherwise it became too verbose.

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