Fixing scipy Version Conflicts Across Machines in the Same Conda Environment

Learn how to resolve `scipy` version mismatches caused by local Python package installations when using identical Conda environments on different machines.
---
This video is based on the question https://stackoverflow.com/q/79426841/ asked by the user 'Carlos Chacon' ( https://stackoverflow.com/u/20667808/ ) and on the answer https://stackoverflow.com/a/79463569/ provided by the user 'Carlos Chacon' ( https://stackoverflow.com/u/20667808/ ) at 'Stack Overflow' website. Thanks to these great users and Stackexchange community for their contributions.

Visit these links for original content and any more details, such as alternate solutions, latest updates/developments on topic, comments, revision history etc. For example, the original title of the Question was: Problems with scipy versions in the same environment but different machines

Also, Content (except music) licensed under CC BY-SA https://meta.stackexchange.com/help/l...
The original Question post is licensed under the 'CC BY-SA 4.0' ( https://creativecommons.org/licenses/... ) license, and the original Answer post is licensed under the 'CC BY-SA 4.0' ( https://creativecommons.org/licenses/... ) license.

If anything seems off to you, please feel free to drop me a comment under this video.
---
The Problem: Different scipy Versions in Identical Conda Environments

You might have encountered a frustrating issue:

You create a Conda environment with a specific version of scipy (e.g., 1.12.0).

The environment is replicated on different machines.

Conda reports the correct scipy version installed on all machines.

Yet, when running Python and importing scipy, different machines show different versions (e.g., 1.13.1 instead of 1.12.0).

This discrepancy causes confusion and can break dependencies, especially if other packages like jax rely on scipy.

Why Does This Happen?

Python's import system looks for packages in multiple places, including:

The active Conda environment's site-packages directory.

User-level directories such as ~/.local/lib/pythonX.Y/site-packages/.

If a conflicting, possibly older or newer, version of scipy exists in the user-level directory outside your Conda environment, Python might pick that up before the environment version, resulting in mismatched scipy versions.

How to Fix It

1. Remove the Conflicting User-Level Installation

Try uninstalling scipy at the user level:

[[See Video to Reveal this Text or Code Snippet]]

If that doesn't work (sometimes it doesn’t if the package was installed manually):

Manually delete the scipy folder from the user site packages:

[[See Video to Reveal this Text or Code Snippet]]

2. Prevent Python from Using User Site Packages

Set an environment variable to tell Python not to include the user site directory when searching for packages.

In your shell (e.g., bash), run:

[[See Video to Reveal this Text or Code Snippet]]

This ensures Python only loads packages from the Conda environment.

Summary

Even when Conda environments match, user-level Python packages can override environment packages.

Removing or disabling user-level packages avoids accidental version conflicts.

Using PYTHONNOUSERSITE=1 is a simple and effective way to force Python to ignore user-installed packages.

This approach helps maintain consistent package versions across different machines and avoids unexpected bugs, especially in data science or machine learning projects integrating packages like jax.