[Qgis-developer] python as plugin

[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
>


-- 
Tim Sutton
QGIS Project Steering Committee Member - Release  Manager
Visit http://qgis.org for a great open source GIS
openModeller Desktop Developer
Visit http://openModeller.sf.net for a great open source ecological
niche modelling tool
Home Page: http://tim.linfiniti.com
Skype: timlinux
Irc: timlinux on #qgis at freenode.net