Closed sphuber closed 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.
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 workflowsPwBaseWorkChain
andPwRelaxWorkChain
with the following entrypoints:The
PwRelaxWorkChain
uses thePwBaseWorkChain
and currently imports it using the absolute pathThe
PwBaseWorkChain
contains basic functionality to deal with crashes of aPwCalculation
. 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 foraiida-quantumespresso-epfl
. This repo also contains aPwBaseWorkChain
that inherits from thePwBaseWorkChain
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.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 thePwBaseWorkChain
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.