[Qgis-developer] Re: plug-in requirements

[Martin Dobias]

Hi,

sorry for a bit late reply...

On Wed, May 14, 2008 at 11:06 AM, Barry Rowlingson
<b.rowlingson at lancaster.ac.uk> wrote:
> 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.

What I was expecting is that developer, once found out that his plugin
is broken will fix it, not that he will just state it's incompatible
with higher versions and re-upload the plugin... But maybe there are
some cases in which max. version would be useful. Here are some syntax
ideas, which do you like most?
1.
  'qgis' = '0.10.0'   # in case of only min. version - or ('0.10.0',
None) but that looks weird
  # or
  'qgis' = ('0.10.0', '0.11.3')  # in case of max. version
2.
  'qgis_min_version' = '0.10.0'  # optional min. version parameter
  'qgis_max_version' = '0.11.3' # optional max. version parameter

I like the second approach more.


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

In fact, I haven't understood what's the reason of your 'test=False' -
is there any scenario when you don't want to check the dependencies?
That return value True / False is meant just for plugin system, but
plugin itself can report errors in any way it likes, using
QgsMessageOutput the most appropriate way will be chosen - if GUI is
not available the errors are reported in console, otherwise a dialog
can be shown. Or do you think that plugins should have unified way to
return dependency errors?

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

You're right, this looks better.

Martin