Plugin versioning

[aiida-bot]

Originally reported by: Andrea Cepellotti (Bitbucket: acepellotti, GitHub: cepellotti)

---

Introduce version support for input/output calculation plugins. In fact, we already need it if we would like to support QE phonon > 5.1.1, since they changed the variable iverbosity -> verbosity.

---

• Bitbucket: https://bitbucket.org/aiida_team/aiida_core/issue/126

[giovannipizzi]

Decide how to deal with this in general with the new plugin system, and document it

[greschd]

I think there are two different topics here: One is how to handle different versions of the code within a given plugin (such as mentioned with QE phonon). The other is how to handle versions of the plugins themselves. For the plugin versions, I think we should require that plugins have a top-level __version__ attribute, since that's the general Python convention.

I'm already using this for the hashing / caching, meaning that nodes from a module which doesn't have a __version__ cannot be cached.

[dev-zero]

Following the discussion today (AiiDA 1.0 Plugin Migration Workshop):

• we need the versioning also for other plugin types (data plugins in particular)
• the reason for the plugin versioning is the in-database/on-disk data which may change on plugin update. Since developers are upgrading their plugins now, it makes sense to have a minimal support in AiiDA 1.0. This is essentially to give plugin-writers a possibility to fail somewhat gracefully if they read data which was written by a newer version of the plugin.
• one idea is to have one version per entrypoint which defaults to the plugins version (using the __version__ attribute), but defaulting to the plugin version (a plugin can contain multiple entrypoints and not necessarily all of them are in-sync wrt versioning)

[sphuber]

Issue #2664 addresses a sub-part of this problem that will already provide a big improvement and will be included in aiida-core==1.0.0. It only includes rules for processes, however, and the granularity of versioning will be limited. It will automatically determine the version based on the top-level module, i.e. the plugin. This version will be shared by all processes and there will be no way to define specific versions per class. In addition, the version attributes will only serve for targeted queries. The logic will not be affected by them.

If these limitations are too strong, and the absence of a version for Data nodes is problematic, they should be discussed here, including potential solutions. But since this will be inherently more complex, I am moving this to the milestone of 2.0.0