Python: import module trouble, depending on running mode

Question

I'm setting up a project, in virtualenv:

py-procr/
  procr/
    bin/
    lib/
    include/
    core/
      pcp.py
      __init__.py
  tests/
    __init__.py
    runner.py

pcp.py:

#!/usr/bin/env python

def hello(msg = "Hello, World!"):
    print(msg)

def zero_pad(i,  n):
    return "%0{n}d"

if __name__ == '__main__':
    hello("Main!")

runner.py:

import unittest
from procr.core.pcp import *

class TestHelpers(unittest.TestCase):

    def setUp(self):
        self.alfa = "alfa"

    def test_zero_pad(self):
        padded_i = zero_pad(3,  5)
        self.assertEqual(padded_i,  "%0{n}d")

if __name__ == '__main__':
    unittest.main()

This is the running pattern:

(procr)a@s ~/spaces/python/py-procr $ python procr/core/pcp.py 
Main!
(procr)a@s ~/spaces/python/py-procr $ python tests/runner.py 
Traceback (most recent call last):
  File "tests/runner.py", line 2, in <module>
    from procr.core.pcp import *
ImportError: No module named 'procr'   ;; also 'core' and 'pcp' if you cut the import statement
(procr)a@s ~/spaces/python/py-procr $ python
Python 3.4.2 (default, Oct  8 2014, 13:44:52) 
[GCC 4.9.1 20140903 (prerelease)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import procr.core.pcp
>>> import tests.runner   ;; runner.py: from procr.core.pcp import *
>>> import tests.runner   ;; runner.py: from core.pcp import *
>>> import tests.runner   ;; runner.py: from pcp import *
>>> import core.pcp
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: No module named 'core'

My Python path:

>>> sys.path
['', '/home/alexey/spaces/python/py-procr/procr/lib/python34.zip', '/home/alexey/spaces/python/py-procr/procr/lib/python3.4', '/home/alexey/spaces/python/py-procr/procr/lib/python3.4/plat-linux', '/home/alexey/spaces/python/py-procr/procr/lib/python3.4/lib-dynload', '/usr/lib64/python3.4', '/usr/lib/python3.4', '/usr/lib/python3.4/plat-linux', '/home/alexey/spaces/python/py-procr/procr/lib/python3.4/site-packages']
>>>

So the IDE/compiler (Eric) is happy; python REPL is happy too, but I can't run my tests.

What's particularly odd about it? I followed such patterns as **mutagen** and **django-oscar** offer. — Alexey Orlov, Dec 07 '14 at 10:26
The test package should not be separate from the rest of the code. — Ignacio Vazquez-Abrams, Dec 07 '14 at 10:28
I was able to run your test using the -m option: python -m tests.runner - addressed in PEP 338 https://www.python.org/dev/peps/pep-0338/ — brobas, Dec 07 '14 at 11:54
This approach does work. Thank you very much, **brobas**! Not even a proper answer to be checked :) . — Alexey Orlov, Dec 07 '14 at 12:40

score 1 · Accepted Answer · edited May 23 '17 at 10:33

1

try running your code using the -m option:

python -m tests.runner

the why is explained in PEP 338:

Python 2.4 adds the command line switch -m to allow modules to be located using the Python module namespace for execution as scripts.

and some answers here as well: What is the -m switch for in Python?

edited May 23 '17 at 10:33

Community

1
1

answered Dec 07 '14 at 18:55

brobas

596
4
5

The ordeal is not over, unfortunately.There's a **mutagen** library. When installed in virtualenv (pip install mutagen), successful import in the REPL, failure while running **pcp.py** script. Uninstalled locally then installed globally (there's the **mutagen** package in the officeal repo of my Linux distro), vice versa: successfully running the script, no import mutagen in the REPL. – Alexey Orlov Dec 09 '14 at 20:04
ack! maybe start a separate question, I pip installed mutagen in the virtualenv and can still run pcp.py and python -m tests.runner under this directory structure with no errors. Also tried putting 'import mutagen' in the pcp.py and no complaints. my pip freeze = mutagen==1.27 wsgiref==0.1.2 – brobas Dec 09 '14 at 20:15
It runs like this:(procr) $ puthon / – Alexey Orlov Dec 10 '14 at 06:40
It runs like this:(procr) $ python procr/core/pcp.py. Just fine, I guess. I have to tell my IDE (Eric) to run debug sessions in virtualenv, which it probably does not. Eric offers a lot of options concerning different executables, etc. I wonder which ones are relevant. – Alexey Orlov Dec 10 '14 at 06:56
**/home/alexey/spaces/python/py-procr/procr/bin/python** Interpreter for the debug client (Eric) helps. This is what virtualenv uses :) . – Alexey Orlov Dec 11 '14 at 01:59
Turned out that ipython is noticeably more forgiving on import issues than the regular python. I wonder why. – Alexey Orlov Dec 25 '14 at 12:35

Python: import module trouble, depending on running mode

1 Answers1