Introduction

The ImportError: No module named nets message usually appears when code from the TensorFlow Object Detection API expects the older TF-Slim model layout, but the local environment does not include it. In other words, the problem is usually not object detection itself, but an environment mismatch between example code, repository layout, and installed Python packages.

Why the nets Import Fails

Older TensorFlow models code often imports modules such as nets.resnet_v1 or nets.mobilenet. Those modules came from the TF-Slim portion of the models repository, not from core TensorFlow.

Typical failing code looks like this:

from nets import mobilenet_v1

That import only works if one of these is true:

• the research/slim directory is on PYTHONPATH
• the relevant code has been installed as a package
• the project has been rewritten to use newer TensorFlow 2 APIs

If none of those are true, Python has no idea where nets lives, so it raises ImportError.

Understand Which Codebase You Are Running

Before fixing the error, determine whether you are using:

• an old TensorFlow 1 tutorial
• the TensorFlow Models repository directly
• a TensorFlow 2 object detection example
• a third-party project copied from an older blog post

This matters because the correct fix depends on the age of the code. Some examples still assume a repository layout like this:

1models/
2  research/
3    object_detection/
4    slim/
5      nets/

In that setup, importing nets works only if Python can see models/research/slim.

Fixing the Environment for Legacy Code

If you intentionally want to run older code, install dependencies and export the expected paths.

A common setup sequence is:

1git clone https://github.com/tensorflow/models.git
2cd models/research
3protoc object_detection/protos/*.proto --python_out=.
4export PYTHONPATH="$PYTHONPATH:$(pwd):$(pwd)/slim"

The important part is $(pwd)/slim, because that directory contains the nets package. Without it, imports such as from nets import resnet_v1 fail even if the repository is cloned correctly.

You can verify the import directly:

python -c "from nets import resnet_v1; print('ok')"

If that command still fails, the active interpreter is probably not using the environment you think it is using.

Virtual Environments Matter

This error often happens because the shell session, IDE, and notebook kernel point to different Python environments. Checking the interpreter path removes guesswork:

which python
python -c "import sys; print(sys.executable)"
python -c "import sys; print('\n'.join(sys.path))"

If models/research/slim does not appear in sys.path, then adding it temporarily or installing the package is still required.

A quick Python-based workaround is:

1import sys
2
3sys.path.append("/path/to/models/research")
4sys.path.append("/path/to/models/research/slim")
5
6from nets import mobilenet_v1

That is useful for debugging, but it is better to fix the environment setup than to scatter sys.path.append() calls throughout the codebase.

Prefer Modern TensorFlow 2 Code When Possible

If you are starting a new project, do not build around legacy nets imports. Modern TensorFlow 2 object detection code usually relies on the official model builder utilities instead of TF-Slim modules imported by hand.

A more current pattern looks like this:

1import tensorflow as tf
2from object_detection.builders import model_builder
3from object_detection.utils import config_util
4
5configs = config_util.get_configs_from_pipeline_file("pipeline.config")
6model_config = configs["model"]
7model = model_builder.build(model_config=model_config, is_training=False)
8print(type(model))

This approach avoids direct dependency on nets in many workflows. If the article or code snippet you copied still imports nets, it may simply be outdated for the TensorFlow version you have installed.

Version Compatibility Is Often the Real Problem

The object detection ecosystem changed substantially between TensorFlow 1 and TensorFlow 2. A project that expects:

• 'tf.contrib'
• TF-Slim
• graph sessions
• old research/slim/nets imports

will not run cleanly in a modern environment without adaptation. In those cases, fixing PYTHONPATH may remove the immediate import error, but more failures often follow.

That is why the first decision should be: preserve legacy code, or migrate to a newer API. If the goal is training or inference in a new project, migration is usually the better use of time.

A Minimal Diagnostic Script

When the problem is unclear, test the import in isolation:

1import importlib.util
2import sys
3
4print(sys.executable)
5print("nets spec:", importlib.util.find_spec("nets"))
6
7try:
8    from nets import resnet_v1
9    print("import succeeded")
10except Exception as exc:
11    print(type(exc).__name__, exc)

This separates environment issues from application-specific issues. If the import fails here, the object detection code is not the primary problem.

Common Pitfalls

• Cloning the models repository but forgetting to add research/slim to PYTHONPATH.
• Running TensorFlow 1 era tutorials in a TensorFlow 2 environment without checking version assumptions.
• Fixing the import in one shell while the notebook or IDE uses a different Python interpreter.
• Adding research to PYTHONPATH but not research/slim, which still leaves nets unresolved.
• Treating the missing module as a TensorFlow install problem when it is really a repository layout problem.

Summary

• 'nets usually comes from TF-Slim inside the TensorFlow models repository, not from TensorFlow core.'
• Legacy object detection code often needs both models/research and models/research/slim on PYTHONPATH.
• Verify the active interpreter before changing imports or reinstalling packages.
• For new work, prefer TensorFlow 2 object detection APIs instead of old TF-Slim-based examples.
• Fixing the import may only be the first step if the codebase targets an older TensorFlow stack.