如何强制 pip 获取 wheel 包(即使是包依赖)?

How to force pip to get a wheel package (even for package dependencies)?

我正在尝试使用一些 python 包构建一个多级 docker 图像。出于某种原因,即使 .whl 文件存在于 Pypi 中,pip wheel 命令仍会下载少数软件包的源文件 .tar.gz。例如:它为 pandas、numpy.

执行此操作

这是我的 requirements.txt:

# REST client
requests

# ETL
pandas

# SFTP
pysftp
paramiko

# LDAP
ldap3

# SMB
pysmb

Dockerfile 的第一阶段:

ARG IMAGE_TAG=3.7-alpine
FROM python:${IMAGE_TAG} as python-base
COPY ./requirements.txt /requirements.txt
RUN mkdir /wheels && \
    apk add build-base openssl-dev pkgconfig libffi-dev
RUN pip wheel --wheel-dir=/wheels --requirement /requirements.txt
ENTRYPOINT tail -f /dev/null

下面的输出显示它正在下载 Pandas 的源包,但它得到了 Requests 包的轮子。此外,令人惊讶的是,下载和构建这些包需要很多时间(我的意思是很多时间)!!

Step 5/11 : RUN pip wheel --wheel-dir=/wheels --requirement /requirements.txt
 ---> Running in d7bd8b3bd471
Collecting requests (from -r /requirements.txt (line 4))
  Downloading https://files.pythonhosted.org/packages/51/bd/23c926cd341ea6b7dd0b2a00aba99ae0f828be89d72b2190f27c11d4b7fb/requests-2.22.0-py2.py3-none-any.whl (57kB)
  Saved /wheels/requests-2.22.0-py2.py3-none-any.whl
Collecting pandas (from -r /requirements.txt (line 7))
  Downloading https://files.pythonhosted.org/packages/0b/1f/8fca0e1b66a632b62cc1ae38e197befe48c5cee78f895edf4bf8d340454d/pandas-0.25.0.tar.gz (12.6MB)

我想知道如何强制它为所有必需的包以及这些包中列出的依赖项获取一个 wheel 文件。我观察到一些依赖项获得了 wheel 文件,而其他依赖项获得了源码包。

注意:上面的代码是多个在线资源的组合。

非常感谢任何有助于简化此构建过程的帮助。

提前致谢。

对于 Python 3,您的软件包将通过普通的 pip 调用从 wheels 安装:

pip install pandas numpy

来自the docs

Pip prefers Wheels where they are available. To disable this, use the --no-binary flag for pip install.

If no satisfactory wheels are found, pip will default to finding source archives.

  1. 您正在使用 Alpine Linux。这个有点独特,因为它使用 musl 作为底层 libc 实现,而不是大多数其他使用 glibc 的 Linux 发行版。

  2. 如果 Python 项目实现 C 扩展(这是 numpypandas 所做的),它有两个选项:

    • 提供一个源 dist(.tar.gz.tar.bz2.zip)以便使用在目标系统上找到的 C compiler/library 编译 C 扩展,或者
    • 提供一个包含已编译 C 扩展的轮子。如果扩展是针对 glibc 编译的,它们将无法在使用 musl 的系统上使用,AFAIK 反之亦然。

现在,Python 定义了 PEP 513 and updated in PEP 571 中指定的 manylinux1 平台标签。基本上,顾名思义 - 带有编译 C 扩展的轮子应该针对 glibc 构建,因此可以在 many 发行版(使用 glibc)上运行,但不适用于 some (Alpine 是其中之一)。

对你来说,这意味着你有两种可能性:要么从源 dists 构建包(这是 pip 已经做的),要么通过 Alpine 的包管理器安装预构建的包。例如。对于 py3-pandas 这意味着做:

# echo "@edge http://dl-cdn.alpinelinux.org/alpine/edge/testing" >> /etc/apk/repositories
# apk update
# apk add py3-pandas@edge

但是,我认为从源代码构建包没有什么大问题。正确完成后,您可以将其捕获在图像中尽可能高的单独层中,因此它会被缓存而不是每次都重建。


您可能会问,为什么没有类似于 manylinux1 的平台标签,但对于基于 musl 的发行版?因为还没有人编写类似于定义 musllinux 平台标签的 PEP 513 的 PEP。如果您对它的当前状态感兴趣,请查看 issue #37.


更新

PEP 656 That defines a musllinux platform tag is now accepted, so it (hopefully) won't last long until prebuilt wheels for Alpine start to ship. You can track the current implementation state in auditwheel#305.