aiidateam / aiida-core

The official repository for the AiiDA code
https://aiida-core.readthedocs.io
Other
437 stars 192 forks source link

Plugin system should allow for entry point override #705

Closed sphuber closed 7 years ago

sphuber commented 7 years ago

We imagine the following use case, that I think will become very common, using Quantum ESPRESSO as an example.

The base repository aiida-quantumespresso is public and free to use and contains among other things two workflows PwBaseWorkChain and PwRelaxWorkChain with the following entrypoints:

"quantumespresso.pw.base = aiida_quantumespresso.workflows.pw.base:PwBaseWorkChain",
"quantumespresso.pw.relax = aiida_quantumespresso.workflows.pw.relax:PwRelaxWorkChain",

The PwRelaxWorkChain uses the PwBaseWorkChain and currently imports it using the absolute path

from aiida_quantumespresso.workflows.pw.base import PwBaseWorkChain

The PwBaseWorkChain contains basic functionality to deal with crashes of a PwCalculation. If someone wants to extend this functionality, but does not want to make that publicly accessible yet, one has to create a separate workchain in a separate private plugin repository. This is exactly what I have done for aiida-quantumespresso-epfl. This repo also contains a PwBaseWorkChain that inherits from the PwBaseWorkChain of the base plugin and extends some of the functionality. As such it has the same entry point as the one of the base plugin, which would cause a conflict.

 "quantumespresso.pw.base = aiida_quantumespresso_epfl.workflows.pw.base:PwBaseWorkChain"

However, in this case this conflict is expected and "desirable" as I want the EPFL version of the PwBaseWorkChain to replace the base one. Likewise, I also want any workflows that want to use the PwBaseWorkChain load the EPFL version when it is installed.

To allow for this behavior we need a way to tell the plugin manager which class to load when there are multiple matches for any given entry point. The dominating class should also be agreed upon by all the registered entry points, such that an entry point cannot be overriden by accident.

sphuber commented 7 years ago

Overriding entry points seems to be the wrong solution to this problem. Instead, to extend the functionality of a certain plugin, the same entry point system should be used and the plugin should allow for plugins to itself. If the functionality really needs to be altered so severely that this solution would become to burdensome, then it stands to reason that the functionality deserves its own distinct entry point and should not override the original one.