pre-commit / mypy results differ from CI on main — how do I align my local toolchain?

[devilfoo]

I am preparing a small contribution, but I’m seeing mismatches between my local checks and what passes in CI. Locally, pre-commit (ruff + mypy) fails with type‑checking errors in files I did not modify, while the main branch appears clean. I suspect a tool‑version or environment drift between my machine and CI.

Steps to Reproduce

git clone https://github.com/TheAlgorithms/Python
cd Python

python -m venv .venv
source .venv/bin/activate   # Windows: .venv\Scripts\activate

python -m pip install --upgrade pip
python -m pip install pre-commit
pre-commit install

pre-commit run --all-files --show-diff-on-failure

python -m pip install mypy
mypy .

Actual Result

Mypy reports errors in unrelated modules (e.g., incompatible types) even though the same files appear to pass CI on main.

Question

What is the correct way to align local tool versions (Python, ruff, mypy, pre‑commit hooks) with the versions used in CI so that local checks match CI behavior?

If type errors appear outside the files I changed, is it recommended to limit checks to staged files or open a separate PR to address repository‑wide issues?

[aayush-dev01]

You’re right — this is almost always caused by tool version or environment drift
between local setup and CI.

🔧 How to align local checks with CI

1. Pin to the repo’s pre-commit tool versions

   • Check .pre-commit-config.yaml for the exact rev values (ruff, mypy, etc.).
   • Then run:

     pre-commit clean
     pre-commit run --all-files

   This ensures your local hooks use the same versions CI uses.

2. Match the Python version used in CI

   • Check the GitHub Actions workflow for the Python version matrix.
   • Create your virtual environment with the same Python version.
   • Python version mismatches commonly surface as mypy errors.

3. Install repo-pinned dependencies

   • Prefer any provided requirements.txt or requirements-dev.txt.
   • Avoid installing tools globally (e.g. pip install mypy) unless CI does the same.

4. Treat pre-commit as the source of truth

   • CI usually runs:

     pre-commit run --all-files

   • Running mypy . directly can differ because pre-commit may pass additional flags
     or configuration options.

📁 About errors in files you didn’t modify

• It’s not expected to fix unrelated type issues in the same PR.
• Recommended approach:
  • Keep the PR focused on your change.
  • If you uncover genuine repo-wide issues, open a separate PR or discussion.
  • Limiting checks to staged files is usually discouraged unless the project
    explicitly recommends it.