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

[Gary Sherman]

On Mar 29, 2008, at 11:17 PM, Marco Hugentobler wrote:
> 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?
>

We can move it to the repository but there is no reason not to have  
'core' Python plugins as well, assuming they are things the QGIS team  
wants to support.

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

Agreed.

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

I really don't see why we should convert a Python plugin to C++. This  
seems to say that we consider Python inferior and not a worthy way to  
create QGIS extensions. Python plugins can reside in core under the  
same conditions/requirements as C++ plugins. I do think we need to  
define the steps and requirements for a plugin (whether C++ or Python)  
to go into core.

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

I will remove it. It was meant as a starter to hopefully get others to  
contribute. It appears that is being done now with the Python  
Geoprocessing plugin.

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

-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-
Gary Sherman
Chair, QGIS Project Steering Committee
-Micro Resources: http://mrcc.com
   *Geospatial Hosting
   *Web Site Hosting
-Desktop GIS Book:
   *http://desktopgisbook.com
"We work virtually everywhere"
-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-