[Qgis-developer] python as plugin

[Marco Hugentobler]

I'm also very much in favor of possibility 2 in order to keep QGIS as modular 
as possible.  

The QGIS mapserver that we use at our institut is an example of an app built 
against the c++ libs. It doesn't use python, but would be harder to compile 
and distribute (fat packages for win that includes all dependencies) with 
option 1.

Regards,
Marco

Am Donnerstag 17 April 2008 17:22:51 schrieb Tim Sutton:
> Hi
>
> 8<------snip-----------
>
> >  This leads me to 2 possibilities:
> >  - make python support a required part of QGIS and integrate the
> >  support directly in the core library
> >  - create a dynamic library with python support - QGIS application or
> >  libraries will try to load the library at run-time. If found, python
> >  support will be done by calls to this library, if not found, support
> >  would be disabled
>
> I prefer option 2. For people creating apps against the c++ libs then
> they wont need to include python in their packaging considerations.
>
> Regards
>
> Tim
>
> >  I think with time and with the amount of nice plugins made in python
> >  it will be inevitable to make python support a required part.
> >
> >  Regards
> >
> > Martin
> >
> >  On Tue, Apr 15, 2008 at 8:11 PM, Jürgen E. Fischer <jef at norbit.de> wrote:
> >  > Hi there,
> >  >
> >  >  I've been thinking about turning the python support into a plugin. 
> >  > If we compile with Python support, we have a static python dependency
> >  > in the qgis binary.
> >  >
> >  >  I think that's an issue for packaging.  With python support as
> >  > plugin, we could split the python plugin into a separate shared
> >  > library.  If python isn't there, the load of the plugin simply fails
> >  > (similar to the GRASS plugin).
> >  >
> >  >  On Debian for instance that would open the possiblity to split off
> >  > the python depencency to a separate package (currently the qgis
> >  > executable itself depends on python) and make providing individual
> >  > packages for different python version easier.
> >  >
> >  >  On Windows we wouldn't need to package python with qgis. We'd just
> >  >  notify the user that python is available and will appear when python
> >  > is installed.
> >  >
> >  >  Maybe we should do the same for GRASS.  Instead of packaging GRASS
> >  > with QGIS on windows, we'd dynamically depend on the WinGRASS package.
> >  >
> >  >  This could be done by implementing plugin providers implemented in
> >  > C++ that allow to load, unload and list available and loaded plugins. 
> >  > The plugin provider would be registered with the plugin registry on
> >  > load.
> >  >
> >  >  Initially there would be a builtin plugin provider for C++ plugins
> >  > and a provider plugin for python plugins.  That plugin would depends
> >  > on the python library and also provide the python bindings.
> >  >
> >  >  That way we could also generalize the handling of plugins in QgisApp
> >  > and the plugin manager and eliminate HAVE_PYTHON there.
> >  >
> >  >  Comments?
> >  >
> >  >
> >  >  Jürgen
> >  >
> >  >  --
> >  >  Jürgen E. Fischer         norBIT GmbH               Tel.
> >  > +49-4931-918175-0 Dipl.-Inf. (FH)           Rheinstraße 13           
> >  > Fax. +49-4931-918175-50 Software Engineer         D-26506 Norden      
> >  >         http://www.norbit.de
> >  >
> >  >  --
> >  >  norBIT Gesellschaft fuer Unternehmensberatung und Informationssysteme
> >  > mbH Rheinstrasse 13, 26506 Norden
> >  >  GF: Jelto Buurman, HR: Amtsgericht Emden, HRB 5502
> >  >
> >  >  _______________________________________________
> >  >  Qgis-developer mailing list
> >  >  Qgis-developer at lists.osgeo.org
> >  >  http://lists.osgeo.org/mailman/listinfo/qgis-developer
> >
> >  _______________________________________________
> >  Qgis-developer mailing list
> >  Qgis-developer at lists.osgeo.org
> >  http://lists.osgeo.org/mailman/listinfo/qgis-developer



-- 
Dr. Marco Hugentobler
Institute of Cartography
ETH Zurich
Technical Advisor QGIS Project Steering Committee