[QGIS-Developer] Understanding plugin management in QGIS: Meta data fields

Etienne Trimaille etienne.trimaille at gmail.com
Tue Mar 31 12:21:47 PDT 2020


Hi,

You will find some answers in the QGIS Documentation about "deprecated",
"hasProcessingProvider" ...
https://docs.qgis.org/3.10/en/docs/pyqgis_developer_cookbook/plugins/plugins.html#plugin-metadata
I'm going to add the "server" one.

> So `experimental` is actually a property of a plugin version. Am I
correctly understanding this?

Yes. Have a look here with the two columns :
https://plugins.qgis.org/plugins/DataPlotly/

> As far as `deprecated` goes, I have not figured out the dynamics yet. Is
it also tied to a version or does a plugin author mark all (past)
versions of a plugin as deprecated by uploading a deprecated "final"
release?

A plugin is deprecated, not a single version. Plugins which are in red
https://plugins.qgis.org/plugins/

For the "trusted", if I'm correct, this does not exist anymore since QGIS
3.0.

A plugin can be designed for desktop or/and for server.
Then a plugin can have or not a processing provider (not related to the
statement before).


Le mar. 31 mars 2020 à 20:35, Sebastian M. Ernst <ernst at pleiszenburg.de> a
écrit :

> Hi everyone,
>
> I am still trying to wrap my head around plugin management. Looking at
> (Python) plugin metadata, I have a few questions.
>
> The meta data contains the fields `experimental` and `deprecated`.
> Having written plugins, I believe that certain versions of a plugin (but
> not "the entire plugin", i.e. all of its versions of it at once) can be
> "experimental". So `experimental` is actually a property of a plugin
> version. Am I correctly understanding this?
>
> As far as `deprecated` goes, I have not figured out the dynamics yet. Is
> it also tied to a version or does a plugin author mark all (past)
> versions of a plugin as deprecated by uploading a deprecated "final"
> release?
>
> What's the story behind `trusted`? I'd guess that plugins of this kind
> can be published without a review and a plugin manager on the client
> should not care about this field.
>
> I understand that `id` is *the* unique identifier for a plugin.
> Eventually, it will be the folder name of the plugin module and it
> usually equals the name of the plugin distribution zip-file (without the
> `.zip` file extension). If this is correct: What's the purpose of
> `zip_repository`? Its description reads "the remote repository id".
>
> Reading through the original plugin manager's code, there are actually a
> few more meta data fields that appear to be undocumented (or at least
> not listed in a central place): `hasProcessingProvider` and `server`,
> both of them more or less booleans. Just to be safe here: Is my
> understanding correct that there are basically three types of Python
> plugins: "regular", server and processing provider?
>
> Best regards,
> Sebastian
> _______________________________________________
> QGIS-Developer mailing list
> QGIS-Developer at lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20200331/00aed40e/attachment.html>


More information about the QGIS-Developer mailing list