覆盖 python setuptools 中的 shebang mangling

Question

背景

我为使用模块 (https://luarocks.org/) 来管理包的系统编写小型 python 包。对于那些不知道的人，您可以运行module load x 并运行一个修改各种环境变量以使软件“x”工作的小脚本，然后您可以使用module unload x 撤消此操作。

这种软件管理方法在科学计算中几乎无处不在，并且在该领域具有很大的价值：您可以运行古老的无人维护的软件以及该软件会干扰的软件包，您可以运行多个版本的软件，这样您就可以准确地重现您的数据（您可以返回旧版本），并且您可以运行具有过时依赖项的编写不佳的未更新软件。

这些功能很棒，但它们会在 python 2/3 拆分时产生问题：

如果您想编写一个与 python 2 和 3 一起使用的包，并将它与 需要 python 2 或 3 的软件一起使用，该怎么办？

让旧的 python2 依赖软件在这些大型系统上工作的方式是创建一个 python/2.7.x 模块和一个 python/3.5 模块。当你想运行一个使用 python 2 的脚本时，你加载那个模块，等等。

但是，我想编写一个可以在 either 环境中工作的单个 python 包，因为无论使用哪个 python 解释器，我都希望该软件处于活动状态。

这基本上非常简单：只需使用#!/usr/bin/env python shebang 行，就完成了。这样可行。我编写了我所有的软件来使用它们，所以没问题。

问题

问题是：我想使用 setuptools 将我的包分发给处于相同情况的其他科学家，而 setup tools 破坏了 shebang 行。

我不想就破坏 shebang 线是否是一个好主意进行辩论，我相信这是因为它已经存在多年，现在处于同一状态。老实说，我不在乎，它对我不起作用。默认的 setuptools 安装会导致软件无法运行，因为当没有加载 python 解释器的模块时，该 python 解释器不起作用，PYTHONPATH 是完全错误的。

如果我的所有用户都有 root 访问权限，我可以使用 data_files 选项将脚本复制到 /usr/bin，但这对于兼容性来说是个坏主意，而且我的用户无论如何都没有 root 访问权限，所以这是一个有争议的问题。

到目前为止我尝试过的事情：

我尝试在setup.py 文件中将sys.executable 设置为/usr/bin/env python，但这不起作用，因为那时shebang 是：#!"/usr/bin/env python"，这显然不起作用。

我在这个问题中尝试了不要碰我的 shebang 类的想法：Don't touch my shebang!（这是 0 票的底部答案）。那也不起作用，可能是因为它是为 distutils 而不是 setuptools 编写的。再加上这个问题已经 6 岁了。

我也看了这些问题：

Setuptools entry_points/console_scripts have specific Python version in shebang

Changing console_script entry point interpreter for packaging

那里描述的方法不起作用，shebang线仍然被改变。

使用内容创建一个setup.cfg 文件::

[build]
executable = /usr/bin/env python

也不会改变 shebang 线修改行为。

在 setuptools github 页面上有一个未解决的问题，讨论了类似的内容：

https://github.com/pypa/setuptools/issues/494

所以我认为这在本地是不可能的，但我想知道是否有解决方法？

最后，我不喜欢任何涉及要求用户修改其安装标志的解决方案，例如-e。

有没有办法修改这种行为，或者我可以使用其他分发系统吗？还是这太过分了，我只需要编写某种自定义安装脚本？

谢谢大家。

---

更新

我认为我最初的问题不够清楚，我希望用户能够做的是：

• 在 python2 和 python3 中安装包（模块将进入 lib/pythonx/site-lib。
• 能够运行 脚本，无论哪个 Python 环境处于活动状态。

如果有办法在不阻止 shebang munging 的情况下实现这一点，那就太好了。

我所有的代码都已经与 python 2.7 和 python 3.3+ 兼容，主要的事情是让脚本运行而不考虑活动的 python 环境。

Answer 1

我在尝试编写自定义安装脚本时无意中发现了一种解决方法。

import os
from setuptools import setup
from setuptools.command.install import install

here = os.path.abspath(os.path.dirname(__file__))

# Generate a list of python scripts
scpts = []
scpt_dir = os.listdir(os.path.join(here, 'bin'))
for scpt in scpt_dir:
    scpts.append(os.path.join(here, 'bin', scpt))

class ScriptInstaller(install):

    """Install scripts directly."""

    def run(self):
        """Wrapper for parent run."""
        super(ScriptInstaller, self).run()

setup(
    cmdclass={'install': ScriptInstaller},
    scripts=scpts,
    ...
)

这段代码并不完全符合我的要求（只改变 shebang 行），它实际上只是将整个脚本复制到 ~/.local/bin，而不是将其包装在::

__import__('pkg_resources').run_script()

此外，更令人担忧的是，此方法使 setuptools 创建一个根模块目录和一个 egg-info 目录，如下所示：：

.local/lib/python3.5/site-packages/cluster
.local/lib/python3.5/site-packages/python_cluster-0.6.1-py3.5.egg-info

而不是一个鸡蛋，这是通常的行为::

.local/lib/python3.5/site-packages/python_cluster-0.6.1-py3.5.egg

据我所知，这是旧 distutils 的行为，这让我担心此安装会在某些系统上失败或出现其他意外行为（尽管如果我错了请纠正我，我真的不是专家关于这个）。

但是，鉴于我的代码将几乎完全在 linux 和 OS X 上使用，这并不是世界末日。我更担心这种行为很快就会消失。

我在 setuptools github 页面上发表了关于开放功能请求的评论：

https://github.com/pypa/setuptools/issues/494

如果我可以在 setup.cfg 中添加一个 executable=/usr/bin/env python 语句，那么理想的解决方案是，希望它很快会重新实现。

这个解决方法现在对我有用。谢谢大家。