[Qgis-psc] python plugins (was: dxf2Shp plugin)

[Marco Hugentobler]

Hi all,

I also think it is important to discuss how to deal with a growing number of 
plugins. It is likely that more plugins for geospatial analisys will appear 
(e.g. I do some work on a plugin for spatial interpolation).

What we need to differentiate is Python plugins and C++ plugins. 

For Python plugins I agree with Gary and Tim that new plugins should go into 
the repository, because it is straightforward to use the plugin installer. 
Maybe even the mapserver export could go to the repository?

For C++ plugins, I'm not so sure what to do (and btw, the dxf2shape plugin is 
a C++ plugin). If we have too many of them in svn, then data volume and 
compile time will grow.
One approach would be to ask the 3rd parties that provide plugin code to host 
their C++ plugins on their own website and build binary packages themselves. 
The QGIS project would then only maintain a page that contains links to the 
3rd party websites. The drawback of this is that it is harder for a user to 
collect the plugins. I therefore think we should still have a selection of 
C++ plugins that we consider as very important in svn.

> I prefer to adopt an approach where when someone whips
> up a python plugin that proves useful, convert it to c++ and introduce
> it to core.

I like this approach. The only drawback is the need for a volunteer to convert 
the code.
The geoprocessing python plugin would be a candidate for such a conversion.

@Gary: there was the suggestion on the mailing list to move the C++ pg 
geoprocessing plugin out of svn because of the python plugin. What is your 
position on this? Can it be removed or are you still using (and maintaining) 
it?


What do you think? 

Regards,
Marco


Am Freitag 28 März 2008 20:47:38 schrieb Tim Sutton:
> Hi
>
> I have a different take on this. Im not really a fan of distributing
> python plugins as they introduce all kinds of new packaging and
> installation headaches and in many cases introduce arbitary new
> dependencies. I prefer to adopt an approach where when someone whips
> up a python plugin that proves useful, convert it to c++ and introduce
> it to core.
>
> Until 1.0 goes out however my feeling is that we should let the python
> repo kinda do its own thing and establish a life of its own, while we
> focus on the core goals of getting 1.0 browser functionality stable.
> Then in the 2.0 cycle we can take a considered approach to building a
> set of spatial analysis tools natively to QGIS core.
>
> Just my 2c
>
> Regards
> Tim
>
> 2008/3/28, Paolo Cavallini <cavallini at faunalia.it>:
> > Gary Sherman ha scritto:
> >  > In general, I'm not in favor of adding python plugins to core and here
> >  > is why. They are generally developed by individuals not on the
> >  > development team. When a plugin gets added to core, we have to support
> >  > it. Already there have been support requests for third-party plugins.
> >  > I prefer to keep core plugins to a minimum and expand the plugin
> >  > repository concept as has been discussed on the mailing lists.
> >  >
> >  > Please let me know your position. I'm afraid if we end up with a bunch
> >  > of core plugins that none of us are familiar with it just adds to the
> >  > support burden and takes away resoures from our core mission.
> >
> >  Another possibility is to lure developers of important plugins (I'm
> >  thinking of geoprocessing for instance) int the core team. I believe
> >  more and more essential development will go to plugins, so I do not
> >  think it will be feasible for long to keep all this wealth out of the
> >  core distribution, and asking users to install them separately.
> >  Futhermore, in multi-users environment having to install plugins for
> >  every user is cumbersome and wasteful.
> >  Anyway, I agree to keep out of core the plugins that we cannot maintain.
> >  pc
> >
> > --
> >  Paolo Cavallini, see: http://www.faunalia.it/pc
> >  Noi ci troviamo con parecchie difficoltà con NGI http://www.ngi.it/
> >  _______________________________________________
> >  Qgis-psc mailing list
> >  Qgis-psc at lists.osgeo.org
> >  http://lists.osgeo.org/mailman/listinfo/qgis-psc



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