The current kimchi plugin subsystem implement a dynamic discovery
and
import mechanism. It uses the Python builtin function __import__() to
actually import a plugin module by name. However it turns out it only
works when we start kimchi from the project source directory, not work
when it is started from the installed path.
This is because the __import__() accepts a "global" arugment and it
needs "__name__", "__path__" and "__package__" in this
"global" dict to
determine the package context [1][2]. When in kimchi/utils.py it runs
"import plugins.XXX", it actually fetch the "__package__" from
utils.py,
which is "kimchi", then it imports "kimchi.plugins.XXX" under the
hood
[3].
The current import_module() function calls __import__() without giving a
global dict. When kimchid is started from /usr/bin, without the package
context, __import__() can not find "plugins.sample".
This patch provides the full package context to __import__() to mimic
the standard "import" statement behavior.
[1]
http://docs.python.org/2/library/functions.html#__import__
[2]
http://hg.python.org/cpython/file/990d7647ea51/Python/import.c
[3]
http://docs.python.org/2/reference/simple_stmts.html#import
Signed-off-by: Zhou Zheng Sheng <zhshzhou(a)linux.vnet.ibm.com>
---
src/kimchi/utils.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/kimchi/utils.py b/src/kimchi/utils.py
index f7eda93..b6d84fd 100644
--- a/src/kimchi/utils.py
+++ b/src/kimchi/utils.py
@@ -83,4 +83,4 @@ def import_class(class_path):
def import_module(module_name):
- return __import__(module_name, fromlist=[''])
+ return __import__(module_name, globals(), locals(), [''])
Reviewed-by:
Mark Wu<wudxw(a)linux.vnet.ibm.com>
Thanks for the fix!