[Qgis-developer] Re: plug-in requirements

[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