[Qgis-developer] Re: plug-in requirements

[Barry Rowlingson]

Martin Dobias wrote:

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

  Right up until backward compatibility breaks, but that'll never 
happen, right? :) Of course when you write plugin Foo for Qgis 0.9.0 you 
don't know that it'll break at 0.10.0, but when 0.10.0 comes out and 
your plugin fails to work, it might be easier to set the requirement to 
 >=0.9.0 and <0.10.0 than fix it for 0.10.0. That was my thinking with 
more complex version checking anyway. It shouldn't be that hard to 
implement.

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

  And it's a pretty trivial test anyway.

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

  I made my custom check function return more than just True or False, 
since I think it's important for plugins to report back on what 
requirements they need, as well as whether those requirements are 
satisfied or not. That way, in a context where testing the requirements 
makes no sense (eg on the plugin server) it's still possible for the 
system to state what's needed. Then the user can get round to sorting 
out those requirements first. With your metadata dict the system can see 
what the dependencies are up to the custom one, at which point all it 
can say is 'Oh, there's some other dependencies'. With my custom 
function, it can call with 'test=False' and get back a descriptive 
string without having to test if the requirements are there or not.

> 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'm not sure calling the dependency fields dep_foo and dep_bar is a 
good idea - I'd have a field called 'dependencies' which would be a dict 
where the values were things like 'foo' and 'bar':

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,
  'dependencies = {
     'gis' : '0.10',
     'plugins' : [ 'myotherplugin', 'mylastplugin' ],
     'python' : [ 'module1', 'module2' ],
     'custom' : my_check,
     }
}

Barry