我正在查看https://github.com/pypa/manylinuxmanylinux1上的库存图像构建脚本，特别是调用链：

• .travis.yml

  /li>

• docker/Dockerfile-<arch>：

  /li>

• docker/build_scripts/build.sh：

  /li>

该脚本假定一个基本的 CentOS 5 文件系统（例如/etc/yum）已经存在。它从何而来？

我没有看到任何对库存图像的引用，也没有看到从某处下载它或使用安装 ISO 之类的任何东西。代码库中也没有/etc任何地方。

我正在尝试构建一个 python 扩展，它使用 numpy C-API 来操作 numpy 数组。在设置部署链时，我遇到了一个问题。

在我requirements.txt和setup.py我添加了依赖项numpy>=1.7，因为我正在使用该版本中引入的 API 功能。我正在quay.io/pypa/manylinux1_x86_64码头图像中建造轮子。在图像内部，我正在使用pip. 这将安装numpy==1.14，因为这是当前版本，与我的依赖项匹配。

但是，当我mypackage-xxx-manylinux_x84_64.whl在我的 ubuntu 机器（有 numpy 1.8）上安装时，我在导入我的包时收到以下错误

明显的解决方法是我运行pip install -U numpy. <1.14但是，如果他们的 numpy 库是（即使它符合我的依赖项要求），我不想告诉我的包的每个用户手动运行此命令。正是这个建议（例如1、 2）有几个问题。我是从包开发人员的角度来问的。我能做些什么来防止这种情况发生？

这里的最佳做法是什么？我是否应该专门添加一个依赖项numpy >= 1.14，以便自动安装此版本？但是，当 numpy 发布新版本时，我的包会自动针对 docker 映像中的新版本构建，这会导致同样的问题。或者我应该明确安装numpy==1.14在 docker 映像中，以获得固定版本并将其添加为依赖项？

或者有没有办法注释轮子，它们是针对哪些 python 包构建的？

PS 当然，源安装没有问题，因为该软件包是针对安装在用户系统上的 numpy 版本构建的。

描述

所以我希望打包一个需要科学库的相当复杂的 python 应用程序。这个问题有点类似于stackoverflow pip 与 conda 的讨论，但它并没有详细说明 linux 轮子的二进制打包自 2016 年以来的差异。我已经看到pypi/cryptography使用 manylinux 并通过 pypi 轮子分发二进制文件。另一个包 mpi4py 仅发布用于 conda 的二进制包，只是因为困难。甚至可以说二元轮不适合这项任务。

问题

与 conda 相比，通过轮子进行的共享库打包看起来像什么？截至 2018 年，通过轮子进行共享库打包是否值得？

要求

我的包裹需要

• 开放式
• fftw3
• 打开mpi
• 灯

在我所有的静态二进制文件中，大约有 100Mb，所以它确实需要很多共享库。许多人还指出，即使对我自己来说，安装也是一种巨大的痛苦……我无法想象如果有人试图自己安装它会是什么样子。到目前为止，我有一个工作的 docker 容器。

为 python 构建 manylinux C++ 扩展的公认方法是在使用 Centos 5.5 作为底层操作系统的 docker 上构建它们。我的扩展有一个 boost 库依赖。小心我可以使用 yum 将 Boost 1.44 库安装到用于构建 python 扩展的 docker 中，这是我目前使用的版本。然而，这限制了我，虽然我在构建这些 IOS 和 Windows 扩展时使用了当前版本的 boost，但我必须非常小心，代码对于 Linux 上的历史 boost 版本 1.44 仍然有效。

什么是最好的可维护方法。如何在保持与 manylinux 兼容的 Centos 5.5 的同时升级 docker 中的 boost 库？我可以实现电流升压兼容性吗？

我正在尝试创建一个使用 BLAS 和 LAPACK C 扩展的 Python 轮子。在 Ubuntu 下编译此类包需要以下系统包：

• libopenblas-dev: (Open)BLAS 开发库
• liblapack-dev: LAPACK 开发库
• liblapacke-dev: LAPACK 的 C 标头

这很好用，但现在我需要在 CentOS 5 下重复这个过程。原因是我正在尝试创建一个 manylinux 轮子，推荐的方法似乎是使用旧的 CentOS 工具链来保证它可以在不同的 linux 发行版下工作.

问题是，虽然在 CentOS 5（libopenblas-dev和）中有等价物，但. 考虑到这些软件包中提供的 LAPACK 版本非常旧（3.0），这似乎是有道理的，它似乎不支持 lapacke。但正因为如此，我无法编译我的软件，因为 gcc 抱怨缺少 lapacke.h 头文件。liblapack-devopenblas-devellapack-develliblapacke-dev

我尝试过的事情：

• 手动下载和编译更新的 LAPACK 版本（3.8.0 和 3.6.0）。我得到编译错误。
• 直接将 lapacke.h 标头从上述 LAPACK 版本之一复制到 /usr/include。没用，可能是因为 LAPACK 版本的不同。
• 按照官方说明添加英特尔 MKL 存储库，并将 BLAS/LAPACK 替换为 MKL。不幸的是 CentOS 5 不包含 中的--add-repo选项yum-config-manager，所以我在这里有点不知所措。

我正在尝试构建一个项目的 python 轮子，为此我必须使用 manylinux（该项目包含 C 和 Fortran 代码）。

当我使用 manylinux 生成轮子时，我得到 6 个文件：

• cp27-cp27m-manylinux1_x86_64.whl
• cp27-cp27mu-manylinux1_x86_64.whl
• cp34-cp34m-manylinux1_x86_64.whl
• cp35-cp35m-manylinux1_x86_64.whl
• cp36-cp36m-manylinux1_x86_64.whl
• cp37-cp37m-manylinux1_x86_64.whl

我知道每个 python 版本都有一个文件，但有人可以解释一下为什么 python 2.7 (cp27m & cp27mu) 有两个文件吗？

I have just started experimenting with CI/CD. I want to create a CI/CD pipeline for my project which builds/tests my application on Linux, MacOS, and Windows. For the Linux part, I need to use a specific Docker container (quay.io/pypa/manylinux2010_x86_64:latest). Before starting the build in the container I do the usual setup (e.g., yum -y upgrade, install CMake, etc). And this is where I am starting to get confused. To my understanding, and after spending sometime Googling, the two most common ways to do that are the following:

1) Build a new Docker container which is based on quay.io/pypa/manylinux2010_x86_64:latest but also comes with other dependencies installed. An example Dockerfile would be the following:

This container is built once and stored in a repository. Then, every time the CI/CD pipeline runs, it fetches and uses this container.

2) Use the quay.io/pypa/manylinux2010_x86_64:latest image in the CI/CD pipeline directly and make the yum -y upgrade and CMake installation commands part of the CI/CD pipeline scripts. This means that every time the CI/CD pipeline runs, it: (a) fetches the docker image, (b) starts the container, (c) runs yum and installs the dependencies.

• Can someone provide me with a list with all the pros, cons, and technical implications of the two approaches? The ones I can think of is that approach (1) spends less time during the CI/CD build, but at the same time, the user has to be responsible for building and hosting the custom Docker image.

• Is any of the two approaches considered a bad practice?

• Given my use-case, could you please help me choose which approach is the right one for me?

FYI: I mostly am interested in the GitLab and GitHub Actions CI/CD services.

嗨，我需要一个 manylinux1 whl 分发，以便一些 python 包在旧服务器上工作。

我找到了manylinux项目并安装了docker。

我的平台是 Windows 10，处理器是 Intel，所以我无法在 VirtualBox 中运行嵌套虚拟化。

那么Windows下应该如何构建docker镜像呢？

非常感谢！

我想构建审计轮并运行命令

我在多个版本的 auditwheel 上遇到这两种错误

和

我已经尝试了几乎所有版本的 auditwheel 安装。你能帮助正确的安装方法吗？

我在 Python 中遇到了一个有线问题，该问题cryptography-2.9.2-cp35-abi3-manylinux2010_x86_64.whl不适用于 SLES 操作系统。

我将 CI/CD 添加到我的存储库中，当我将包从 requirements.txt 下载到本地文件夹时dist-packages。Jenkins Slave 机器在 RedHat Linux 上运行。因此，它使用此文件下载，cryptography-2.9.2-cp35-abi3-manylinux2010_x86_64.whl而我的运行时在 SLES OS 11 中，这需要cryptography-2.9.2-cp35-abi3-manylinux1_x86_64.whl.

这个特定的依赖cryptography-2.9.2-cp35-abi3-manylinux2010_x86_64.whl是从 RedHat 下载的，当我将它重新分发到 SLES OS 时，这个依赖失败并出现以下错误。

如果我将依赖项名称从更改cryptography-2.9.2-cp35-abi3-manylinux2010_x86_64.whl为cryptography-2.9.2-cp35-abi3-manylinux1_x86_64.whl它在 SLES OS 机器上工作正常。

当我签入 PyPI https://pypi.org/project/cryptography/#modal-close（这两个文件大小相同但哈希值不同）

我想了解 python 包中 manylinux1_x86_64 与 manylinux2010_x86_64 之间的区别。

提前致谢。