Relative imports - ModuleNotFoundError: No module named x

Question

This is the first time I've really sat down and tried python 3, and seem to be failing miserably. I have the following two files:

1. test.py
2. config.py

config.py has a few functions defined in it as well as a few variables. I've stripped it down to the following:

config.py

debug = True

test.py

import config
print (config.debug)

I also have an __init__.py

However, I'm getting the following error:

ModuleNotFoundError: No module named 'config'

I'm aware that the py3 convention is to use absolute imports:

from . import config

However, this leads to the following error:

ImportError: cannot import name 'config'

So I'm at a loss as to what to do here... Any help is greatly appreciated. :)

Answer 1

TL;DR: You can't do relative imports from the file you execute since __main__ module is not a part of a package.

Absolute imports - import something available on sys.path

Relative imports - import something relative to the current module, must be a part of a package

If you're running both variants in exactly the same way, one of them should work. Here is an example that should help you understand what's going on. Let's add another main.py file with the overall directory structure like this:

.
./main.py
./ryan/__init__.py
./ryan/config.py
./ryan/test.py

And let's update test.py to see what's going on:

# config.py
debug = True

# test.py
print(__name__)

try:
    # Trying to find module in the parent package
    from . import config
    print(config.debug)
    del config
except ImportError:
    print('Relative import failed')

try:
    # Trying to find module on sys.path
    import config
    print(config.debug)
except ModuleNotFoundError:
    print('Absolute import failed')

# main.py
import ryan.test

Let's run test.py first:

$ python ryan/test.py
__main__
Relative import failed
True

Here "test" is the __main__ module and doesn't know anything about belonging to a package. However import config should work, since the ryan folder will be added to sys.path.

Let's run main.py instead:

$ python main.py
ryan.test
True
Absolute import failed

And here test is inside of the "ryan" package and can perform relative imports. import config fails since implicit relative imports are not allowed in Python 3.

Hope this helped.

P.S.: If you're sticking with Python 3 there is no more need for __init__.py files.

Answer 2

You have to append your project's path to PYTHONPATH and make sure to use absolute imports.

---

For UNIX (Linux, OSX, ...)

export PYTHONPATH="${PYTHONPATH}:/path/to/your/project/"

For Windows

set PYTHONPATH=%PYTHONPATH%;C:\path\to\your\project\

---

Absolute imports

Assuming that we have the following project structure,

└── myproject
    ├── mypackage
    │   ├── __init__.py
    │   ├── a.py
    └── anotherpackage
        ├── __init__.py
        ├── b.py
        ├── c.py
        └── mysubpackage
            ├── __init__.py
            └── d.py

just make sure to reference each import starting from the project's root directory. For instance,

# in module a.py
import anotherpackage.mysubpackage.d

# in module b
import anotherpackage.c
import mypackage.a

---

For a more comprehensive explanation, refer to the article How to fix ModuleNotFoundError and ImportError

Answer 3

I figured it out. Very frustrating, especially coming from python2.

You have to add a . to the module, regardless of whether or not it is relative or absolute.

I created the directory setup as follows.

/main.py
--/lib
  --/__init__.py
  --/mody.py
  --/modx.py

modx.py

def does_something():
    return "I gave you this string."

mody.py

from modx import does_something

def loaded():
    string = does_something()
    print(string)

main.py

from lib import mody

mody.loaded()

when I execute main, this is what happens

$ python main.py
Traceback (most recent call last):
  File "main.py", line 2, in <module>
    from lib import mody
  File "/mnt/c/Users/Austin/Dropbox/Source/Python/virtualenviron/mock/package/lib/mody.py", line 1, in <module>
    from modx import does_something
ImportError: No module named 'modx'

I ran 2to3, and the core output was this

RefactoringTool: Refactored lib/mody.py
--- lib/mody.py (original)
+++ lib/mody.py (refactored)
@@ -1,4 +1,4 @@
-from modx import does_something
+from .modx import does_something

 def loaded():
     string = does_something()
RefactoringTool: Files that need to be modified:
RefactoringTool: lib/modx.py
RefactoringTool: lib/mody.py

I had to modify mody.py's import statement to fix it

try:
    from modx import does_something
except ImportError:
    from .modx import does_something


def loaded():
    string = does_something()
    print(string)

Then I ran main.py again and got the expected output

$ python main.py
I gave you this string.

Lastly, just to clean it up and make it portable between 2 and 3.

from __future__ import absolute_import
from .modx import does_something

Answer 4

Setting PYTHONPATH can also help with this problem.

Here is how it can be done on Windows

set PYTHONPATH=.

Answer 5

You can simply add following file to your tests directory, and then python will run it before the tests

__init__.py file

import os
import sys
sys.path.insert(0, os.path.abspath(os.path.join(os.path.dirname(__file__), '..')))

Answer 6

Set PYTHONPATH environment variable in root project directory.

Considering UNIX-like:

export PYTHONPATH=.

Answer 7

If you are using python 3+ then try adding below lines

import os, sys
dir_path = os.path.dirname(os.path.realpath(__file__))
parent_dir_path = os.path.abspath(os.path.join(dir_path, os.pardir))
sys.path.insert(0, parent_dir_path)

Answer 8

Tried your example

from . import config

got the following SystemError:
/usr/bin/python3.4 test.py
Traceback (most recent call last):
File "test.py", line 1, in
from . import config
SystemError: Parent module '' not loaded, cannot perform relative import

---

This will work for me:

import config
print('debug=%s'%config.debug)

>>>debug=True

Tested with Python:3.4.2 - PyCharm 2016.3.2

---

Beside this PyCharm offers you to Import this name.
You hav to click on config and a help icon appears.

Answer 9

Declare correct sys.path list before you call module:

import os, sys

#'/home/user/example/parent/child'
current_path = os.path.abspath('.')

#'/home/user/example/parent'
parent_path = os.path.dirname(current_path)

sys.path.append(parent_path)
os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'child.settings')

Answer 10

I am working in a Linux machine. I had the same issue when I run python my_module/__main__.py.

The error is fixed, if you run the command export PYTHONPATH=. before your run your script.

export PYTHONPATH=.
python my_module/__main__.py

Answer 11

Try

from . import config

What that does is import from the same folder level. If you directly try to import it assumes it's a subordinate

Answer 12

This example works on Python 3.6.

I suggest going to Run -> Edit Configurations in PyCharm, deleting any entries there, and trying to run the code through PyCharm again.

If that doesn't work, check your project interpreter (Settings -> Project Interpreter) and run configuration defaults (Run -> Edit Configurations...).

Answer 13

You may use these statements to set the working directory, which worked for me with python3

import os
import sys
sys.path.insert(1, os.getcwd())

Answer 14

As was stated in the comments to the original post, this seemed to be an issue with the python interpreter I was using for whatever reason, and not something wrong with the python scripts. I switched over from the WinPython bundle to the official python 3.6 from python.org and it worked just fine. thanks for the help everyone :)

Answer 15

For me, simply adding the current directory worked.

Using the following structure:

└── myproject
    ├── a.py
    └── b.py

a.py:

from b import some_object
# returns ModuleNotFound error

from myproject.b import some_object
# works

Answer 16

I see many answers importing sys and os. Here's a not mentioned yet shorter one that GitHub Copilot gave me:

import sys

sys.path.append(__file__.rsplit("/", 1)[0])

Adding this to the top of my python script solved the problem as well.

Answer 17

In my experience, PYTHONPATH environment variable does not work everytime.

In my case, my pytest only worked when I added the absolute path: sys.path.insert( 0, "/Users/bob/project/repo/lambda" )

Answer 18

To have Bash automatically recognise the project dir you're in:

sudo nano ~/.bashrc

OR

sudo nano ~/.bash_profile

At the bottom of the bash file:

function set_pythonpath {
    export PYTHONPATH="$(pwd):$PYTHONPATH"
}

PROMPT_COMMAND=set_pythonpath

To save and exit:

• Ctrl + X
• Y

Test your changes by:

cat ~/.bashrc

Answer 19

The existing answers do well to explain the possible causes of the issue. For those cases where the Exception results from attempted relative imports, I find the following approach can help resolve:

1. Search project files for from .
2. Update all those imports to absolute imports
3. Use absolute imports for all new imports

It's a pain, and less flexible, but helps avoid circular-import-caused errors.

Another common, albeit less-common, cause for these issues in my experience is conflicting namespaces. This error tends to be the most insidious to debug as there is rarely an indication of conflicts in error messaging.

In almost all cases, it takes manual context-specific debugging. However, general example would be:

.
└── root/
    ├── apps/
    │   ├── ...
    |   |── app2/
    │   └── app2/
    │       ├── ...
    │       └── main.py
    └── venv/
        ├── ...
        └── Lib/
            └── site-packages/
                ├── ...
                └── django/
                    ├── ...
                    └── apps

In the root/apps/app1/main.py file, imagine you import something from apps.app2 and also try from django.apps. That will cause an issue in most cases because apps enters the namespace from two locations.

However, the error message is usually something that leads one to believe it's a circular import a imports b and b imports a when really it's confusion over what a and b really are.