[Qgis-developer] Re: plug-in requirements

[Marco Hugentobler]

Hi all,

I'm looking forward to such a sophisticated plugin metadata system. And the 
possibility to let a plugin depend on other plugins will be a great thing. 

Though when implementing the wfs plugin and provider, I learned that plugins 
linking to other plugins can be a problem on Mac (at least for C++ plugins). 

> I wanted to implement this in near time and thus get it ready for 1.0
> however it looks that Gary wants to release 1.0 ASAP so I'm not sure
> whether such change is feasible and it will have to wait for post-1.0
> with other things like geometry-refactor and provider-refactor.

Right, probably after 1.0

Regards,
Marco 

Am Mittwoch 14 Mai 2008 10:40:50 schrieb Martin Dobias:
> On Wed, May 14, 2008 at 12:07 AM, Barry Rowlingson
>
> <b.rowlingson at lancaster.ac.uk> wrote:
> >  Here's some more thinking:
> >
> >  plugins should define a "requirements" function in their __init__.py
> > file which will look something like this:
> >
> >  def requirements():
> >   reqs = {
> >     'qgis': ['>=0.9.0','<0.11.0'] ,
> >     'qgis-plugins': [],
> >     'python': '>=2.3.0',
> >     'python-packages': ['rpy'],
> >     'rpy-r': '>=2.4.0',
> >     'r-packages': ['DCluster'],
> >     'other': otherRequirements,
> >     }
> >   return reqs
>
> Hi Barry,
>
> few days ago I've tried to do a design for the new plugins
> architecture, the part regarding the plugin requirements looked like
> this (how I would implement it):
>
> __init__.py:
>
> metadata = {
>  'name' : 'my plugin',
>  'description' : 'i like my plugin',
>  'author' : 'super programmer',
>  'version' : '1.0.3',
>  'url' : 'http://www.example.com/myplugin',
>  'interface' : QgsPlugin.SomePluginIface,
>  'dep_qgis' : '0.10',
>  'dep_plugins' : [ 'myotherplugin', 'mylastplugin' ],
>  'dep_python' : [ 'module1', 'module2' ],
>  'dep_custom' : my_check
> }
>
> def my_check():
>   """ some custom tests, returning True means success """
>   return True
>
> def create_instance():
>   """ import plugin class and run it """
>   from myplugin import MyPlugin
>   return MyPlugin()
> ---------
>
> There are several things to note:
> - __init__.py shouldn't have any imports in the top part of file (to
> save loading time if the plugin is not going to be used anyway)
> - the dictionary 'metadata' should contain everything that is related
> to the loading, dependency checking etc. - in current version we use
> name(), description() etc. as functions - actually this should be
> avioded as the values are static, so there's no reason to have them
> like functions
> - some fields (like dep. on other plugins, custom check) can be optional
> - in check of QGIS version I'm using only minimal version. After some
> thinking I've come out that this is the most reasonable type of check.
> If someone really depends on some special range of versions, then he
> could extend the check in custom dependency checking phase.
> - in comparison with Barry's scheme of requirements I haven't included
> python version check - in fact it should be included too (someone may
> use some newer python constructs not supported in previous versions).
> The other two fields 'rpy-r' and 'r-packages' are really specific to
> R, so checks for these must go to custom check function.
> - custom check function in my design does its own checks and then
> returns True or False depending on whether all checks went well. For
> the error reporting it can use e.g. QgsMessageOutput class.
> - there is a field 'interface' which defines what type of plugin do we
> have here. As noted in some previous threads, currently we have just
> one plugin type - GUI plugin, but it's necessary to support more
> types, some of them should be available also for core library (e.g.
> renderers).
>
> This scheme of metadata passing and dependency checking should be the
> same for C++ and Python plugins, except for the part with Python deps.
> In my design I've made a draft of changes in qgis libs and app, but I
> think this is not important now.
>
> I wanted to implement this in near time and thus get it ready for 1.0
> however it looks that Gary wants to release 1.0 ASAP so I'm not sure
> whether such change is feasible and it will have to wait for post-1.0
> with other things like geometry-refactor and provider-refactor.
>
> Please comment!
>
> Martin
> _______________________________________________
> Qgis-developer mailing list
> Qgis-developer at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer



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