You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
version of numpy included does not allow pyarrow to be used #1372
Description:
setup-python@v7 for version Python 3.11 comes with numpy 1.26.4 included and then pyarrow returns the error that it requires numpy >=2.0.
I hit that problem when my github action runs the test automation. For that it imports pyarrow and that's where it fails.
Action version:
v7
Platform:
Ubuntu
macOS
Windows
Runner type:
Hosted
Self-hosted
Tools version:
Python 3.11
Repro steps:
pip install pyarrow
python myscript.py
myscript.py should import pyarrow.
Expected behavior:
This poses multiple questions:
Why is numpy even installed? Okay, so that others do not have to install it. But then the version must be current also.
Why such an old version?
How can I control which libraries are being installed? I assume I cannot because it is a package that gets downloaded.
You cannot really blame pyarrow to check the version, so I would not call it a bug on their side.
Actual behavior:
I have validated that my pip install does not include numpy.
Pyarrow also does not include numpy as dependency.
But if numpy is present, it checks its version - and that is the problem.
I can deal with that situation via two ways:
add numpy 2.0 as a requirement, package it hence into my code (Azure function) and then not use it.
pip uninstall before installing the requirements. Also not nice.
A fresh virtual environment keeps the shared installation's NumPy out of the test environment, without changing the shared packages or adding NumPy to your deployment requirements. setup-python selects an interpreter; it does not create a clean project environment on each run.
For example, keep this in one Bash step after setup-python:
Do not use --system-site-packages, and use the same venv Python for installation and execution. For your application, install its existing requirements in that environment instead; if its operations actually need NumPy, they still need a compatible version. The pip configuration override above is for the public package index—adapt it deliberately if you use a private index.
Arrow documents NumPy as optional. I put a complete runnable example and self-hosted job snippet here: it imports PyArrow without NumPy and checks two IPC and two Parquet round trips. The local check uses Python 3.12.4 on macOS; the supplied Python 3.11 job has not been run on your runner. Without your traceback and PyArrow version, this does not establish where the existing NumPy came from or whether your application uses a NumPy-dependent path.
Activity
v-priyagupta108 commentedon Oct 16, 2026
Hello @wernerdaehn,
Thank you for creating this issue. We will investigate it and provide feedback as soon as we have some updates.
tevinch commentedon Oct 19, 2026
A fresh virtual environment keeps the shared installation's NumPy out of the test environment, without changing the shared packages or adding NumPy to your deployment requirements.
setup-pythonselects an interpreter; it does not create a clean project environment on each run.For example, keep this in one Bash step after
setup-python:Do not use
--system-site-packages, and use the same venv Python for installation and execution. For your application, install its existing requirements in that environment instead; if its operations actually need NumPy, they still need a compatible version. The pip configuration override above is for the public package index—adapt it deliberately if you use a private index.Arrow documents NumPy as optional. I put a complete runnable example and self-hosted job snippet here: it imports PyArrow without NumPy and checks two IPC and two Parquet round trips. The local check uses Python 3.12.4 on macOS; the supplied Python 3.11 job has not been run on your runner. Without your traceback and PyArrow version, this does not establish where the existing NumPy came from or whether your application uses a NumPy-dependent path.