0

We are publishing binry wheels for a python package on PyPi. The package has a Fortran extension which we produce with f2py.

Our problem is that the CI images (Gitlab CI for Linux and Appveyor for Windows) tend to have the newest numpy version. Then, when the user installs the binary wheel, the Fortran extension will fail unless the user also has the newest numpy version.

This problem was also described in this SO question.

The proposed solution in the accepted answer was to add a pyproject.toml file containing an older numpy version as a build dependency, like this:

[build-system] requires = ['numpy==1.15', 'setuptools', 'wheel'] build-backend = "setuptools.build_meta" 

and then to require at least that version on the user machine through the install_requires in setup.py, like `'numpy>=1.12.2'.

I tried that, but now it seems that in the Gitlab CI, pip again installs the newest numpy version, which is what I wanted to avoid in the first place.

A part of the output is copied below. In the first lines it says Installing build dependencies and I assume it installs numpy 1.15 then. But later, it says Collecting numpy>=1.15 and Using cached numpy-1.20.1-cp37-cp37m-manylinux2010_x86_64.whl (15.3 MB). So, it doesn't keep the previously installed numpy 1.15 (if any) but overwrites it with the newest version.

My question is, how can I avoid that and make sure that exactly numpy 1.15 is used for the creation of the binary wheel?

$ pip3 install -e . Obtaining file:///builds/AmosEgel/smuthi Installing build dependencies: started Installing build dependencies: finished with status 'done' Getting requirements to build wheel: started Getting requirements to build wheel: finished with status 'done' Preparing wheel metadata: started Preparing wheel metadata: finished with status 'done' Collecting mpmath Downloading mpmath-1.2.1-py3-none-any.whl (532 kB) Collecting psutil Downloading psutil-5.8.0-cp37-cp37m-manylinux2010_x86_64.whl (296 kB) Collecting imageio Downloading imageio-2.9.0-py3-none-any.whl (3.3 MB) Collecting scipy Downloading scipy-1.6.2-cp37-cp37m-manylinux1_x86_64.whl (27.4 MB) Collecting pycparser Downloading pycparser-2.20-py2.py3-none-any.whl (112 kB) Collecting argparse Downloading argparse-1.4.0-py2.py3-none-any.whl (23 kB) Collecting sympy Downloading sympy-1.7.1-py3-none-any.whl (5.9 MB) Collecting matplotlib Downloading matplotlib-3.3.4-cp37-cp37m-manylinux1_x86_64.whl (11.5 MB) Collecting tqdm Downloading tqdm-4.59.0-py2.py3-none-any.whl (74 kB) Collecting h5py Downloading h5py-3.2.1-cp37-cp37m-manylinux1_x86_64.whl (4.1 MB) Collecting pywigxjpf Downloading pywigxjpf-1.11.tar.gz (54 kB) Collecting numba Downloading numba-0.53.0-cp37-cp37m-manylinux2014_x86_64.whl (3.4 MB) Collecting pyyaml Downloading PyYAML-5.4.1-cp37-cp37m-manylinux1_x86_64.whl (636 kB) Collecting numpy>=1.15 Using cached numpy-1.20.1-cp37-cp37m-manylinux2010_x86_64.whl (15.3 MB) 

1 Answer 1

0

Ok, the problem was that one of the other requirements (in our case, h5py) required a more recent version of numpy.

Sign up to request clarification or add additional context in comments.

1 Comment

You should not install your package with pip before building a wheel from it. As you saw that also installs the runtime requirements, which you wanted to avoid.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.