R: [Qgis-developer] python as plugin

[Marco Pasetti]

Hi Jürgen,

You touched a *hot* point, in my opinion.

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

Actually, it would be, and in fact it is, a good idea, that let things
(packaging, morevover) very simple and tidy... but this is (I mean: good),
IMHO, specially for unix-like unsers; I try to explain: I'm both windows and
linux (just a bit) user, so I'm used to the habits of windows users, and I
can understand some other habits of linux ones. If on linux is usual and
very simple to download and install the required *optional* packages to
enable some special *features* (such as qgis plugins) into specific
applications, on the other side, this is not definetely the same for windows
users. It's a consolidated *windows* habit to install and use *complete*
software packages only, without the need to install further *pieces* of
softwares to let the formers work as their well. For this reason, I guess
that, for windows, it would be a *strategic* decision to release a
self-contained, *full-featured* version of the installer; even if a lot less
tidy and efficient, it would guarantee us the best diffusion among windows
users.

>Maybe we should do the same for GRASS.  Instead of packaging GRASS with
QGIS on windows, we'd dynamically depend on the WinGRASS package.

The same lines I wrote above could reply the dynamic GRASS plugin proposal.
I confirm, it's a good idea, why not? (please, remember that I'm also a
GRASS dev-team member, so to not support your proposal could be in contrast
with my GRASS position...). But there's still many reasons, for windows
packaging, to say no. IMHO, again, who uses GRASS toolbox in QGIS, instead
of using GRASS itself, does it because the QGIS GRASS toolbox is more easy
and intuitive (even if less powerful) than the full GRASS. For the same
reasons that I explained above, I believe that users (specially from windows
world) who prefer QGIS GRASS toolbox (instead of GRASS itself), and/or
rarely use GRASS but still have the need to use it sometimes, would be very
unhappy to must install GRASS as separate package instead of having it
pre-packaged in QGIS.

Thank you for reading my opinions ;-)

Marco


-----Messaggio originale-----
Da: qgis-developer-bounces at lists.osgeo.org
[mailto:qgis-developer-bounces at lists.osgeo.org] Per conto di Jürgen E.
Fischer
Inviato: martedì 15 aprile 2008 20.12
A: qgis-developer at lists.osgeo.org
Oggetto: [Qgis-developer] python as plugin

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