How to deal with relative imports in a Python package

Question

I'm working on a Python project with approximately the following layout

project/
    foo/
        __init__.py
        useful.py
        test/
            __init__.py
            test_useful.py

test_useful.py tries to import project.foo.useful so it can test it, but it doesn't work when I say "python project/foo/test/test_useful.py", but it does work if I copy it into my current directory and run "python test_useful.py".

What is the correct way to handle these imports while developing? It seems like this won't be an issue once installed, because it will be in PYTHONPATH. Should I use distutils to make a build/ folder and add it to my PYTHONPATH?

Answer 1

First of all you need to set up your PYTHONPATH to either include "project" or the parent of "project". This is important while you're developing too :-)

Then you should be able to use an absolute import:

from project.foo import useful

Secondly, I would suggest that instead of running tests by executing the module, you install py.test (pip install pytest). Then you'll be able to use relative imports, as long as your py.test invocation is generic enough (ie "py.test foo" will work, but "py.test foo/test/test_useful.py" will not). I would still recommend that you not use relative imports in tests.

Answer 2

Please consider using distutils/setuptools to make your project installable in a Python standard way. (Hint: you'll need to create a setup.py file parallel to the 'foo' directory, also known as a package.)

Doing so will also allow you to then use a number of common Python testing frameworks (nose, py.test, etc.) to make it possible to collect and run tests, where most such frameworks automatically ensure 'foo' is an importable package before running the tests. Your test_useful.py tests can them import 'foo.useful' without a problem.

Also worth noting from your example directory structure is that it seems to be generally recommended that your tests directory NOT be a Python package. ie delete the test/ init .py file. The framework will ensure the tests are runnable, and not having it as a package will help ensure it only gets distributed in source distributions and not binary ones (where it likely isn't wanted.)