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@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(), ['']) -- 1.7.11.7