Where’s your code? Debugging ImportErrors in your Docker image
Your code runs fine on your computer, but when you try to package it with Docker you keep getting
ImportErrors: Python can’t find your code.
There are multiple reasons why this can happen, some of them Python-specific, some of them Docker-specific. So let’s go through a step-by-step process to figuring out what the problem is, and how to fix it.
Step 1. Are you using the right Python interpreter?
It’s easy to mistakenly end up with multiple Python interpreters in your Docker image. When that happens, you might install your code with interpreter A, but try to run it with interpreter B—which then can’t find the code.
Here’s a somewhat contrived example of how this happens:
FROM python:3.8-slim-buster RUN apt-get update && apt-get install -y python3 python3-pip RUN /usr/bin/pip3 install flask ENTRYPOINT ["python", "-c", "import flask"]
You now have two Python interpreters:
/usr/local/bin/pythonis the Python interpreter provided by the Docker image. This is what the
/usr/bin/python3is the Python interpreter installed via
apt-get. This is what
Sometimes this happens less visibly, when you install a system package that depends on a
python3 system package.
This mostly happens if you’re (mis)using the official
python base image.
If you are:
- Don’t manually install Python.
- If you’re installing system packages, check if Python is one of the dependent system packages installed, and if so make sure you’re using the
Step 2. If relevant, are you successfully activating your virtualenv/conda env?
If you’re using an isolated environment like a virtualenv or Conda environment, you’re in a similar situation to the above: you have two different versions of Python, the system Python and the isolated environment. You want to make sure your code is installed and run from the same one.
Step 3. If it’s not
pip installed, make sure the code location is correct
This is where you need to start understanding how Python decides where you can import code from.
To begin with, Python has a series of standard directories where it checks for imports.
You can seem them by looking at
$ docker run -it python:3.8-slim-buster Python 3.8.3 (default, Jun 9 2020, 17:49:41) [GCC 8.3.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import sys >>> sys.path ['', '/usr/local/lib/python38.zip', '/usr/local/lib/python3.8', '/usr/local/lib/python3.8/lib-dynload', '/usr/local/lib/python3.8/site-packages']
We’ll ignore that first item, the
'', for now.
The next few are basically just to give you access to the Python standard library.
The last entry, ending with
site-packages, is where
pip will install packages.
So long as you’re installing your code with
pip, you’re all good.
It doesn’t matter what directory you’re in, you will be able to import it successfully.
$ docker run -it python:3.8-slim-buster bash root@3c19e2314f01:/# pip install --quiet flask root@3c19e2314f01:/# python -c "import flask; print('success')" success root@3c19e2314f01:/# cd /tmp root@3c19e2314f01:/tmp# python -c "import flask; print('success')" success
The problem usually arises when you’re not installing code with
pip, but rather just copying it into some arbitrary directory.
That’s where the first entry in
sys.path, the blank string
'', comes into effect.
'' means is “add the directory where the initial script you ran is to
Since that may be a little confusing, let’s look at two examples.
Let’s say we have two files,
main.py will do an
If they are in the same directory, everything will work:
$ tree . └── code ├── library.py └── main.py 1 directory, 2 files $ python code/main.py Successfully imported library.py $ cd code/ $ python main.py Successfully imported library.py
If they are in different directories, the import will fail:
$ tree . ├── code │ └── library.py └── main.py 1 directory, 2 files $ python main.py Traceback (most recent call last): File "main.py", line 1, in <module> import library ModuleNotFoundError: No module named 'library' $ cd code/ $ python ../main.py Traceback (most recent call last): File "../main.py", line 1, in <module> import library ModuleNotFoundError: No module named 'library'
Notice that your current working directory doesn’t matter. What matters is that the code you’re importing is in the same directory as the main script you’re running.
Either install all your code with
pip install, or make sure it’s all in the same directory.
python -m requires the code to be in the current working directory
If you’re using
python -m yourpackage or
python -m yourmodule, and you haven’t just
pip installed everything, then you need to follow the same requirements as step 3: the imported code needs to be in the same directory as the main script.
In addition, your current directory (which you can set in your
WORKDIR), must be the same directory where your code sits.
$ tree . └── code ├── library.py └── main.py 1 directory, 2 files $ python -m main /usr/bin/python: No module named main $ cd code/ $ python -m main Successfully imported library.py
If your code is a package, you need to be in the directory containing the package:
$ tree . ├── library.py └── myapp ├── __init__.py └── __main__.py 1 directory, 3 files $ python -m myapp Successfully imported library.py $ cd myapp/ $ python -m myapp /usr/bin/python: No module named myapp
Make sure your current working directory is the same as the code:
FROM python:3.8-slim-buster WORKDIR /code COPY myapp .
The short version
To recap, here are the suggested actions to take to prevent
- Make sure you only have one version of Python installed.
- If you’re using a virtualenv/conda env, make sure it’s correctly activated.
- Either install all your code with
- Make sure it’s all in the same directory.
- If you’re additionally using
python -m, make sure your working directory is the same as the directory the code resides in.
Want to learn more debugging techniques for common Docker packaging problems? There’s a whole chapter covering 13 different debugging techniques in Just Enough Docker Packaging, my introductory book for Python programmers.
Learn how to build fast, production-ready Docker images—read the rest of the Docker packaging guide for Python.
Docker packaging is complicated, and you can’t afford to screw up production
From fast builds that save you time, to security best practices that keep you safe, how can you quickly gain the expertise you need to package your Python application for production?
Take the fast path to learning best practices, by using the Python on Docker Production Checklist.
Learn practical Docker and Python software engineering skills, every week
You need to stay competitive in the job market—but there's too much to learn, and you don’t know where to start.
Join over 1800 Python developers and data scientists learning practical tools and techniques, from Docker packaging to Python best practices, with a free new article in your inbox every week.