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

Question

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

这是我的要求.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 文件，而其他依赖项获得了源包。

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

非常感谢任何使此构建过程更容易的帮助。

提前致谢。

Answer 1

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

2. 如果一个 Python 项目实现了 C 扩展(例如 numpy 或 pandas 所做的)，它有两个选择:要么

   • 提供源代码(.tar.gz、.tar.bz2 或 .zip)以便使用 C 扩展编译在目标系统上找到的 C 编译器/库，或者
   • 提供一个包含已编译的 C 扩展的轮子。如果扩展是针对 glibc 编译的，它们将无法在使用 musl 的系统上使用，据我所知，反之亦然。

现在，Python 定义了在PEP 513 中指定的manylinux1 平台标签。并在 PEP 571 中更新.基本上，顾名思义 - 带有编译 C 扩展的轮子应该针对 glibc 构建，因此可以在许多发行版(使用 glibc)上运行，但不适用于一些( 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定义一个 musllinux 平台标签现在被接受，所以它(希望)不会持续很长时间，直到 Alpine 的预制轮子开始发货。您可以在 auditwheel#305 中跟踪当前的实现状态.