如何强制 pip 获取 Wheel 包（即使是包依赖项）？

Question

我正在尝试使用一些 python 包构建多级 docker 映像。由于某种原因，即使Pypi 中存在文件，pip wheel命令仍然会下载少数包的源文件。例如：它为 pandas、numpy 执行此操作。.tar.gz.whl

这是我的要求.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)

我想知道如何强制它获取所有必需的包以及这些包中列出的依赖项的轮文件。我观察到一些依赖项获取轮文件，但其他依赖项获取源包。

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

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

提前致谢。

Answer 1

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

2. 如果一个Python项目实现了C扩展（这就是egnumpy或pandas所做的），它有两个选择：

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

现在，Python 定义了PEP 513manylinux1中指定并在PEP 571中更新的平台标签。基本上，这个名字说明了一切——带有编译的 C 扩展的轮子应该针对 glibc 构建，因此可以在许多发行版（使用 glibc）上运行，但不能在某些发行版上运行（Alpine 就是其中之一）。

对你来说，这意味着你有两种可能性：要么从源代码构建包（这已经是这样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 的发行版的平台标签？因为还没有人编写过类似于 PEP 513 的 PEP 来定义musllinux平台标签。如果您对它的当前状态感兴趣，请查看问题#37。

更新

PEP 656定义的musllinux平台标签现已被接受，因此（希望）它不会持续很长时间，直到 Alpine 的预制车轮开始发货。您可以在auditwheel#305中跟踪当前的实施状态。