Document inability to control plugin execution order

This commit is contained in:
Justin Mayer 2020-07-29 06:41:28 +02:00
commit 6289452e95

View file

@ -70,8 +70,8 @@ How to create plugins
===================== =====================
Plugins are based on the concept of signals. Pelican sends signals, and plugins Plugins are based on the concept of signals. Pelican sends signals, and plugins
subscribe to those signals. The list of signals are defined in a subsequent subscribe to those signals. The list of available signals is documented in a
section. subsequent section.
The only rule to follow for plugins is to define a ``register`` callable, in The only rule to follow for plugins is to define a ``register`` callable, in
which you map the signals to your plugin logic. Let's take a simple example:: which you map the signals to your plugin logic. Let's take a simple example::
@ -94,6 +94,10 @@ which you map the signals to your plugin logic. Let's take a simple example::
your ``register`` callable or they will be garbage-collected before the your ``register`` callable or they will be garbage-collected before the
signal is emitted. signal is emitted.
If multiple plugins connect to the same signal, there is no way to guarantee or
control in which order the plugins will be executed. This is a limitation
inherited from Blinker_, the dependency Pelican uses to implement signals.
Namespace plugin structure Namespace plugin structure
-------------------------- --------------------------
@ -272,3 +276,4 @@ Adding a new generator is also really easy. You might want to have a look at
.. _Pip: https://pip.pypa.io/ .. _Pip: https://pip.pypa.io/
.. _pelican-plugins bug #314: https://github.com/getpelican/pelican-plugins/issues/314 .. _pelican-plugins bug #314: https://github.com/getpelican/pelican-plugins/issues/314
.. _Blinker: https://pythonhosted.org/blinker/