[Kimchi-devel] [PATCH] plugin: fix dynamic import mechanism

Aline Manera alinefm at linux.vnet.ibm.com
Fri Jan 3 12:24:40 UTC 2014


On 01/03/2014 12:41 AM, Zhou Zheng Sheng wrote:
> on 2014/01/02 20:30, Aline Manera wrote:
>> On 01/02/2014 08:41 AM, Sheldon wrote:
>>> Reviewed-by: ShaoHe Feng <shaohef at linux.vnet.ibm.com>
>>> Tested-by: ShaoHe Feng <shaohef at linux.vnet.ibm.com>
>>>
>>> I have find this problem, when I run test.
>>> $ sudo ./run_tests.sh test_rest
>>> Failed to import plugin plugins.sample.Drawings
>>>
>>> this patch has fixed this problem.
>>>
>> I am still getting the import error while running mockmodel tests:
>>
>> alinefm at alinefm:~/kimchi/tests$ sudo ./run_tests.sh test_mockmodel
>> Failed to import plugin plugins.sample.Drawings
>>
>> Is it another issue or this patch should fix it too?
>>
> Thanks Aline and Sheldon. The problem you found is a different one. That
> is because the plugins sub-directory is not in the import path when we
> run the test.
>
> When installed , the plugins sub-directory is in
> python_site_packages/kimchi/plugins, so after this patch, importing
> "kimchi.plugins.sample" and "plugins.sample" can both succeed. However
> when running test from the tests/ directory, the kimchi source is in
> ../src/kimchi while plugins is in ../plugins, so neither
> "kimchi.plugins.sample" nor "plugins.sample" would succeed.
>
> This patch only to fix the use of the __import__() function for the
> installed kimchi directory structure. If we want to fix the import
> problem in unit test, I can submit another patch. Agree?

Yes.

>>> On 12/31/2013 08:21 PM, Zhou Zheng Sheng wrote:
>>>> 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 at 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(), [''])
>>>
>




More information about the Kimchi-devel mailing list