Introduction

Installing TensorFlow 1.10 on macOS El Capitan is a legacy compatibility task, not a normal modern setup. The safest way to approach it is to isolate the environment with an older Python version in a virtual environment, accept that you are targeting CPU execution, and keep dependency versions conservative.

Start with realistic constraints

TensorFlow 1.10 is from the TensorFlow 1.x era. That means:

• Python support is old
• package wheels may not exist for every interpreter build
• GPU setup on an old Mac is usually not the practical path
• modern system Python and modern package sets are often a poor fit

So the first goal is stability, not novelty. Use a dedicated environment and avoid mixing it with a current Python toolchain.

Create a compatible Python environment

A Python 3.6 virtual environment is usually the most practical starting point for TensorFlow 1.10.

1python3.6 -m venv tf110-env
2source tf110-env/bin/activate
3python --version
4pip install --upgrade "pip<21" setuptools wheel

Pinning pip below very new releases is a defensive choice for old environments. It reduces the chances of hitting packaging behavior that the legacy stack was never designed around.

Once the environment is active, install TensorFlow and the basic scientific stack:

pip install "numpy<1.16" "six<2" "protobuf<4"
pip install "tensorflow==1.10.0"

If the wheel installs cleanly, verify it immediately rather than layering more packages on top first.

Verify the installation early

1python - <<'PY'
2import tensorflow as tf
3print(tf.__version__)
4a = tf.constant(3)
5b = tf.constant(4)
6with tf.Session() as sess:
7    print(sess.run(a + b))
8PY

A successful run proves more than pip list does. TensorFlow 1.x can install and still fail later because of binary or dependency mismatches, so a tiny session-based test is the right verification step.

Expect legacy friction on El Capitan

The biggest installation risk is not the TensorFlow command itself. It is the age mismatch between the operating system, compiler tools, Python build, and available wheels. If you are forced onto this stack for an old project, keep the environment minimal and resist the urge to upgrade supporting packages casually.

If direct installation fails because a matching wheel is unavailable or compilation breaks, the practical fallback is to run the old project in Docker or on a Linux virtual machine with a period-appropriate Python stack. That often saves time compared with forcing a fragile native macOS installation to behave.

Why virtual environments matter even more here

With legacy packages, accidental dependency drift is the main source of pain. A virtual environment gives you one isolated place to pin everything, export requirements, and avoid colliding with modern machine learning tooling.

For a project like this, reproducibility matters more than convenience. Once the environment works, freeze it and leave it alone.

Common Pitfalls

• Trying to install TensorFlow 1.10 into a modern default Python and expecting compatibility.
• Mixing old TensorFlow with aggressively updated versions of numpy, protobuf, or packaging tools.
• Treating GPU support on an old Mac as the default path instead of using CPU-only installation.
• Declaring success after pip install without running a real TensorFlow 1.x session test.
• Continuing to upgrade packages after you finally reach a working legacy environment.

Summary

• Treat TensorFlow 1.10 on El Capitan as a legacy compatibility setup.
• Use an older Python environment, isolate it, and keep dependencies conservative.
• Verify the install with a real TensorFlow 1.x session-based script.
• Prefer CPU execution unless you have a very specific, proven GPU path.
• If native installation becomes too fragile, containerizing the legacy stack is often the better answer.