# import error: 'No module named' *does* exist

I am getting this stack trace when I start pyramid pserve:

% python $(which pserve) ../etc/development.ini Traceback (most recent call last): File "/home/hughdbrown/.local/bin/pserve", line 9, in <module> load_entry_point('pyramid==1.5', 'console_scripts', 'pserve')() File "/home/hughdbrown/.virtualenvs/ponder/local/lib/python2.7/site-packages/pyramid-1.5-py2.7.egg/pyramid/scripts/pserve.py", line 51, in main return command.run() File "/home/hughdbrown/.virtualenvs/ponder/local/lib/python2.7/site-packages/pyramid-1.5-py2.7.egg/pyramid/scripts/pserve.py", line 316, in run global_conf=vars) File "/home/hughdbrown/.virtualenvs/ponder/local/lib/python2.7/site-packages/pyramid-1.5-py2.7.egg/pyramid/scripts/pserve.py", line 340, in loadapp return loadapp(app_spec, name=name, relative_to=relative_to, **kw) File "/home/hughdbrown/.virtualenvs/ponder/lib/python2.7/site-packages/PasteDeploy-1.5.2-py2.7.egg/paste/deploy/loadwsgi.py", line 247, in loadapp return loadobj(APP, uri, name=name, **kw) File "/home/hughdbrown/.virtualenvs/ponder/lib/python2.7/site-packages/PasteDeploy-1.5.2-py2.7.egg/paste/deploy/loadwsgi.py", line 271, in loadobj global_conf=global_conf) File "/home/hughdbrown/.virtualenvs/ponder/lib/python2.7/site-packages/PasteDeploy-1.5.2-py2.7.egg/paste/deploy/loadwsgi.py", line 296, in loadcontext global_conf=global_conf) File "/home/hughdbrown/.virtualenvs/ponder/lib/python2.7/site-packages/PasteDeploy-1.5.2-py2.7.egg/paste/deploy/loadwsgi.py", line 320, in _loadconfig return loader.get_context(object_type, name, global_conf) File "/home/hughdbrown/.virtualenvs/ponder/lib/python2.7/site-packages/PasteDeploy-1.5.2-py2.7.egg/paste/deploy/loadwsgi.py", line 454, in get_context section) File "/home/hughdbrown/.virtualenvs/ponder/lib/python2.7/site-packages/PasteDeploy-1.5.2-py2.7.egg/paste/deploy/loadwsgi.py", line 476, in _context_from_use object_type, name=use, global_conf=global_conf) File "/home/hughdbrown/.virtualenvs/ponder/lib/python2.7/site-packages/PasteDeploy-1.5.2-py2.7.egg/paste/deploy/loadwsgi.py", line 406, in get_context global_conf=global_conf) File "/home/hughdbrown/.virtualenvs/ponder/lib/python2.7/site-packages/PasteDeploy-1.5.2-py2.7.egg/paste/deploy/loadwsgi.py", line 296, in loadcontext global_conf=global_conf) File "/home/hughdbrown/.virtualenvs/ponder/lib/python2.7/site-packages/PasteDeploy-1.5.2-py2.7.egg/paste/deploy/loadwsgi.py", line 337, in _loadfunc return loader.get_context(object_type, name, global_conf) File "/home/hughdbrown/.virtualenvs/ponder/lib/python2.7/site-packages/PasteDeploy-1.5.2-py2.7.egg/paste/deploy/loadwsgi.py", line 681, in get_context obj = lookup_object(self.spec) File "/home/hughdbrown/.virtualenvs/ponder/lib/python2.7/site-packages/PasteDeploy-1.5.2-py2.7.egg/paste/deploy/util.py", line 68, in lookup_object module = __import__(parts) File "/home/hughdbrown/.virtualenvs/ponder/local/lib/python2.7/site-packages/ponder-0.0.40-py2.7.egg/ponder/server/__init__.py", line 10, in <module> from ponder.server.views import Endpoints, route ImportError: No module named views  This works fine from a python REPL: % python Python 2.7.5+ (default, Feb 27 2014, 19:37:08) [GCC 4.8.1] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from ponder.server.views import Endpoints, route >>>  and from a command line import: % python -c "from ponder.server.views import Endpoints, route"  An abridged tree output shows what I am working with: % tree ├── __init__.py ├── ponder │ ├── __init__.py │ ├── server │ │ ├── __init__.py │ │ └── views │ │ ├── environment_templates.py │ │ ├── groups.py │ │ ├── __init__.py │ │ ├── instances.py │ │ ├── tasks.py │ │ └── users.py  My PYTHONPATH is set to the root of this tree: % echo$PYTHONPATH
/home/hughdbrown/workspace/ept/ponder/lib


I am running this in a virtualenv that uses python 2.7. I have had this working off and on today but I can’t figure out where the problem is. For one thing, the __init__.py seems to be okay with some imports that come just before:

from .database import get_db
from .config import parser
from .views import Endpoints, route


(I changed the last line to an absolute import. No luck.)

Things that I have tried:

1. Rebuilding virtualenv

2. Setting PYTHONPATH

3. Using absolute paths in code

4. Looking for circular imports

I am open to further suggestions in how to debug this error.

So the mistake I made was to look only at the source tree. The problem was really in the runtime environment, in my virtualenv. And when I looked there, I found that the desired files were not being installed. The problem, at root, was the setup.py.

## Here is Solutions:

We have many solutions to this problem, But we recommend you to use the first solution because it is tested & true solution that will 100% work for you.

### Solution 1

I set the PYTHONPATH to '.' and that solved it for me.

export PYTHONPATH='.'


For a one-liner you could as easily do:

PYTHONPATH='.' your_python_script


These commands are expected to be run in a terminal

### Solution 2

My usual trick is to simply print sys.path in the actual context where the import problem happens. In your case it’d seem that the place for the print is in /home/hughdbrown/.local/bin/pserve . Then check dirs & files in the places that path shows..

You do that by first having:

import sys


in python 3 with the print function:

print(sys.path)


or in python 2 with print expression:

print sys.path


### Solution 3

I had the same problem, and I solved it by adding the following code to the top of the python file:

import sys
import os

sys.path.append(os.path.dirname(os.path.dirname(os.path.dirname(__file__))))


Number of repetitions of os.path.dirname depends on where is the file located your project hierarchy. For instance, in my case the project root is three levels up.

### Solution 4

The PYTHONPATH is not set properly. Export it using export PYTHONPATH=\$PYTHONPATH:/path/to/your/modules .

### Solution 5

I met the same problem, and I try the pdb.set_trace() before the error line.

My problem is the package name duplicate with the module name, like:

test
├── __init__.py
├── a
│   ├── __init__.py
│   └── test.py
└── b
└── __init__.py


and at file a/__init__.py, using from test.b import xxx will cause ImportError: No module named b.

### Solution 6

They are several ways to run python script:

• run by double click on file.py (it opens the python command line)
• run your file.py from the cmd prompt (cmd) (drag/drop
your file on it for instance)

Each of these ways can run a different version of python (¤)

Check which python version is run by cmd:
Type in cmd:

python --version


Check which python version is run when clicking on .py:

option 1:

create a test.py containing this:

import sys print (sys.version)
input("exit")


Option 2:

type in cmd:

assoc .py
ftype Python.File


Check the path and if the module (ex: win32clipboard) is recognized in the cmd:

create a test.py containing this:

python
import sys
sys.executable
sys.path
import win32clipboard
win32clipboard.__file__


Check the path and if module is recognized in the .py

create a test.py containing this:

import sys
print(sys.executable)
print(sys.path)
import win32clipboard
print(win32clipboard.__file__)


If the version in cmd is ok but not in .py it’s because the default program associated with .py isn’t the right one. Change python version for .py

To change the python version associated with cmd:

Control Panel\All Control Panel Items\System\Advanced system setting\Environnement variable
In SYSTEM variable set the path variable to you python version (the path are separated by ;: cmd use the FIRST path eg: C:\path\to\Python27;C:\path\to\Python35 → cmd will use python27)

To change the python version associated with .py extension:

Write: ftype Python.File="C:\Python35\python.exe" "%1" %* It will set the last python version (eg. python3.6). If your last version is 3.6 but you want 3.5 just add some xxx in your folder (xxxpython36) so it will take the last recognized version which is python3.5 (after the cmd remove the xxx).

Other:

“No modul error” could also come from a syntax error btw python et 3 (eg. missing parenthesis for print function…)

¤ Thus each of them has it’s own pip version

### Solution 7

I had the same issue. I solved it by running the command in a different python version. I tried python3 filename.py. Earlier i was using Python 2.7.

Another possibility is that the file from which something is imported may contain BOM (Byte Order Mark). It can be solved by opening the file in some editor which supports multiple encoding like VSCode (Notepad++) and saving in a different encoding statndard like ANSI, UTF-8(without BOM).

### Solution 8

If you have a script with the same name as your module in another directory, it will use that instead. For example:

module.py

module
|
|--module
|  |
|  |--__init__.py
|  |--module.py


This will make it so that the first module.py is being used, not the second one.

### Solution 9

In case this is of interest to anyone, I had the same problem when I was running Python in Cygwin, in my case it was complaning that pandas wasn’t installed even though it was. The problem was that I had 2 installations of python – one in windows and another one in cygwin (using the cygwin installer) and although both were the same versions of Python, the Cygwin installation was confused about where Pandas was installed. When i uninstalled cygwin’s Python and pointed Cygwin at the windows installation everything was fine

### Solution 10

I got this when I didn’t type things right. I had

__init.py__


__init__.py


### Solution 11

I’ve had this problem too, I had just forgotten to type workon myproject in the terminal before executing my program.

### Solution 12

My issue is that I had two directories in my sys.path / PYTHONPATH – a project root directory, and an apps directory within Django.

I was trying to reach a Python module inside the apps directory, but by chance had an identically named folder in the root. Python was finding the directory in the root, and so not finding the directory in the apps directory.

(Duh. Although I’m partly writing this as I’ll find myself back here in a few months/years..)

Note: Use and implement solution 1 because this method fully tested our system.
Thank you 🙂