This was caused by accessing the cache using the passed in mod_type
rather than the suffix that we calculate with knowledge of whether this
is a module or non-module plugin.
Code for a plugin is usually loaded by a PluginLoader(), and henceforth
available from self._module_cache, which prevents duplicate loading.
However there are situations (e.g. where one action plugin imports code
from another one) where the plugin module might be already imported (and
resident in sys.modules), but not present in the PluginLoader's
_module_cache, which causes imp.load_source() to effectively reload the
module, overwriting global class declarations and causing subtle latent
bugs.
Fixes#13110.
Fixes#12979.
* Don't throw away the full path of the module code being loaded,
as this can cause conflicts when files of the same name are being
instantiated
* Generalize the module loading code
Fixes#12738
Fixes bugs related to creating Templar() objects on the fly, where
the shared loader objects (serialized to TaskExecutor) aren't used
so information loaded into plugin loaders after forking is lost.
Fixes#11815
added deprecation warning
fixed display.deprecated to make version optional (code already assumed this)
turned warning + 'deprecated' in plugin loader into actual call to deprecated()
* PluginLoader class will now be more selective about loading some
plugin classes, if a required base class is specified (used to avoid
loading v1 plugins that have changed significantly in their apis)
* Added ability for the connection info class to read values from a
given hosts variables, to support "magic" variables
* Added some more magic variables to the VariableManager output
* Fixed a bug in the ActionBase class, where the module configuration
code was not correctly handling unicode
Kishin Yagami
Toshio Kuratomi
James Cammarata
Marius Gedminas
Brian Coca
Chris Church
Matt Martz