[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 wenzeslaus):

 Replying to [comment:4 zarch]:
 >
 > 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.
 >
 I cannot comment on `G_gisinit` much but the error is that the DLL is not
 found, so I though that it is before the call.
 >
 > > 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
 }}}
 >
 This is what I do too, the same for `grass.script`. But `grass.script` is
 an example where some things were used for compatibility and changes in
 internal structure are expected in the future I would say. But generally,
 yes, it seems that it is better to have empty `__init__.py` files.

 I'm not sure if it is better to move `pygrass.modules` outside of
 `pygrass` or not. I was not thinking about it much. However, it seems that
 `pygrass.modules` is really something different from the library
 interface. The only connection is that it is new and Pythonic and it was
 implemented together. The `ctypes` dependency is quite a big difference.
 I'm not sure if there will be something in the future which would
 introduce `ctypes` to modules. Perhaps yes, for example some command line
 parsing interface using GRASS parser (based on library rather then on
 `g.parser`). What would be the name of a standalone package? Just
 `grass.modules`?

 > 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:
 >
 > Otherwise it became too verbose.

 I agree, this is really internal and `__init__.py` should be used to hide
 it.

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