关于用 pip .whl 安装预编译的可执行文件的踩坑

[Contextualist]

TL; DR: setup.py 里的 data_files

之前写了个包，核心部分是用 Go 写的一个独立可执行文件。因为不想碰 C extention 那套机制，所以采用了独立可执行文件与 Python 主进程 Unix Domain Socket 通信的方式。这样，通过 PyPI 分发包的时候就需要安装时将那个二进制文件放在用户 bin 目录下。

上网查出来的方案都是在 setup .py 里用 package_data 保留文件，然后用 cmdclass 里安装时的 hook 来执行安装后移动文件的命令。于是我按照这个方式硬写了个，还得手动检测路径（sys.prefix 和 --user 什么的）。本地从源码安装测试是行得通，但用 wheel 文件安装时，那个 hook 就不执行了。又不优雅又不方便🤷‍♂️

我就去看看 setup .py 的文档，还真就找到了 data_files 这个用来在安装后放置文件的选项。可以通过这个将文件放在用户指定的安装 prefix 下，所以我的问题加一行设置就解决了 data_files=[('bin', ['path/to/my/binary',]),], （会在安装后将 binary 放在 {prefix}/bin/ 上）。

不过话说回来，这个预编译的 Go 可执行文件并不跨平台（我这个包本来是只针想对 Linux 平台开发的），而这样一番操作下来得到的是通用的 wheel 文件，总感觉不怎么严谨。之前写 cython 拓展的时候做过 manylinux 的 wheel，不知道这种不涉及 C extention 的怎么搞？

[ampedee]

长知识了。
不过我觉得是你一开始查的方案的锅。官方文档以及 setuptool 的文档都有很详细的说明怎么处理非代码的数据文件。

[Rheinmetal]

看看 pep 517 518 ？

[Contextualist]

@ampedee 看了一下官方文档，似乎大部分的篇幅都在讲 package_data 这个保留数据文件的方式（但这个不能将文件移动到包自身路径以外的位置）。

@Rheinmetal 看了一下这两个 PEP 似乎是讲将构建的后端开放给 Poetry 或 Flit 一类第三方构建工具，而不局限于 setuptools 。

其实我苦恼的应该是找不到一个官方或者非官方的指南讲解如何在构建过程中纳入别的语言的编译（能找到的基本都在讲 C extension ）。然后 Python 的打包生态总体比较割裂，历史遗留问题也多。感觉 Anaconda 在分发预编译文件这方面的好像考虑得比较多（不过他们的依赖解析器实在是太难用了。

[Rheinmetal]

两个 pep 目的是取消含有魔法的 setup.py
问题是现在就要魔法.....
检测平台下载对应的 go binary 这种
还是下载 go 源码当场构建？

[frostming]

然后用 cmdclass 里安装时的 hook 来执行安装后移动文件的命令

安装 hook 当然对 wheel 不生效，因为你用错了 hook，应该 hook build command，在这个 command 里执行 go build 然后配合 data_files 去映射路径，build wheel 的时候不要选--universal 就不会产出跨平台的 wheel

[Contextualist]

@Rheinmetal 原来如此。看了一下 Poetry 好像就把额外的构建步骤放在 build.py 里了。我还是倾向分发已经编译好的二进制文件，毕竟这也是 wheel 的初衷。

@frostming 感谢点拨，用上了 build hook，然后加上了 --plat-name=manylinux1_x86_64 选项。