[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Python3 search path order when building Debian package



Hi,

During the build of oslo packages for OpenStack, I'm having the issue
that python3 seems to first look into
/usr/lib/python3.4/dist-packages/olso, finds stuff in it, and then do
not search in the local directory. Because of that, unit tests are
failing during the build. For example, when trying to build
python-oslo.utils (new package, not yet available in Debian), I get:

======================================================================
FAIL: unittest.loader.ModuleImportFailure.tests.test_excutils
unittest.loader.ModuleImportFailure.tests.test_excutils
----------------------------------------------------------------------
_StringException: Traceback (most recent call last):
ImportError: Failed to import test module: tests.test_excutils
Traceback (most recent call last):
  File "/usr/lib/python3.4/unittest/loader.py", line 312, in _find_tests
    module = self._get_module_from_name(name)
  File "/usr/lib/python3.4/unittest/loader.py", line 290, in
_get_module_from_name
    __import__(name)
  File
"/home/zigo/sources/openstack/juno/python-oslo.utils/build-area/python-oslo.utils-0.1.1/tests/test_excutils.py",
line 22, in <module>
    from oslo.utils import excutils
ImportError: No module named 'oslo.utils'

note that I am running testr the following way:

testr-python3 init
PYTHON=python3.4 testr-python3 run --subunit | subunit2pyunit

Of course, if I first install python3-oslo.utils, then the unit tests
are passing without any issue. Though at build time, the package isn't
installed in the system yet.

What's very surprising to me, is that I have this issue only with Python
3, not with python 2.7, which passes the tests without any issue, and
does the path hunt for the python module correctly.

For other oslo libraries, I have declared some Build-Conflicts, to make
sure that they aren't installed in the system when building. Though that
can't be done with oslo.utils, because it depends on oslo.config and
oslo.i18n.

I think this highlight once more that using namespace should be avoided
if possible. This creates more issues than it solves problems.

Any idea, comment or whatever that may help would be appreciated.

Cheers,

Thomas Goirand (zigo)

P.S: By the way, there's issues with python-oslo.utils with Python 3.4,
after solving the above problem...


Reply to: