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)
Amos Egel
  • 937
  • 10
  • 24

1 Answers1

0

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

Amos Egel
  • 937
  • 10
  • 24
  • 1
    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. – renefritze Mar 26 '21 at 14:23