[Qgis-developer] python as plugin

[Martin Dobias]

Hi,

thanks for starting this discussion. I've been thinking about possible
solutions for python support and moving all python support to a plugin
was one of them. But I've realized that this won't be a good idea. The
reason is that we won't be able to continue the integration with
Python.

>From my longer-term vision, we're just in the first phase of
integration of Python with QGIS. Now python support is implemented in
QGIS application, thus it has nothing to do with core or gui library.
My target is to support python also in the libraries - this will bring
even better possibilities for Python programmers since they would be
able to create own data providers, renderers and more plugin types in
python. (So far, only data provider plugins and gui plugins are
currently supported, but in future we'll have to enable more types of
plugins such as renderers and more).

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