如何在 Python 包的 distutils 安装的构建阶段编译 CoffeeScript？

Posted 2023-02-24

【中文标题】如何在 Python 包的 distutils 安装的构建阶段编译 CoffeeScript？

【英文标题】：How can one compile CoffeeScript during the build phase of a Python packages' distutils installation?

【发布时间】：2012-05-22 21:32:12

【问题描述】：

我正在开发一个 Python Django 包，它的前端组件使用了一些 CoffeeScript。

现在，我有一个相当脑残的外部脚本来处理 CoffeeScript 编译。它只是为 src/coffee/ 目录中的每个 *.coffee 文件运行 coffee 编译命令，并将输出存储在 src/static/js 中——这类似于 python ./setup.py build_ext --inplace 在开发中存储 C 扩展的构建文件的方式源代码树。

这目前可行，但它很俗气——它强制使用平面目录结构，并修改 src/static 中的文件（这与“静态”所暗示的相反）。

我希望最大限度地使用 Python，因此我研究了将 distutils.ccompiler.CCompiler 修改为运行 coffee 作为 setup.py "build_ext" 子命令的子命令——我设想能够执行以下操作：

% python ./setup.py build_coffee
% python ./setup.py build_coffee --inplace
% python ./setup.py build_ext --inplace # implying 'build_coffee --inplace'

...但我发现 distutils 的编译器 API 过于关注在这种情况下没有类似物的 C 编译细微差别，例如预处理、链接等。我还查看了 Cython 的代码（特别是 Cython 的 CCompiler 子类，它将 .pyx 文件预处理为 .c 源代码），但这看起来同样专业，不适合这种情况。

有没有人有一个用 distutils setup.py 脚本编译 CoffeeScript 的好解决方案？或者，除此之外，还有一个好的替代建议？

【问题讨论】：

看看github.com/jezdez/django_compressor，不知道是否适合你的需求

我实际上在我的基础项目中使用了这个包，在这个项目中我正在开发这个包以及一个使用它的网络应用程序。这是一个很棒的包，但它的重点是在 Web 上下文中自动部署已编译/压缩的资产——我不能将它用作通用先决条件。我正在寻找更多与 Cython 如何与 distutils 一起使用的内容（例如，如果您安装了它，它将根据需要进行预处理和编译）。我的潜在用户可能没有以相同的方式安装 CoffeeScript，并且他们的 webapp 部署方法可能与 django-compressor 不兼容。

绑定到 django 的 collectstatic 命令有什么问题？

没什么问题。它只是在 Python 包的 distutils 安装的构建阶段不编译 CoffeeScript（这是我想要做的）。

【参考方案1】：

您可以将其滚动到自定义的 manage.py 命令中。 See the official Django documentation here 这样，每次服务器运行时都会运行脚本，从而始终生成干​​净的 js。

【讨论】：

好电话——既然你提到了它，那在很多方面对于这类事情来说都是一个更健康的地方。谢谢和问候。

【参考方案2】：

你可以有一个 pre-commit hook* 将 coffescript 编译成 javascript。

因此，每次您在 coffescript 中提交更改时，javascript 版本都会更新。

*pre commit hook：实现方式取决于您使用的 VCS，并取决于您使用的是健全的 VCS。

【讨论】：

其实我喜欢预提交钩子——我主要使用 git；在这方面，这并不是那么疯狂——事实上，我此时正在调用我的俗气的编译批处理脚本，并带有一个预提交钩子。这对我的开发需求以及可能对从 GitHub 克隆它的患者和感兴趣的人来说都很好，但是将“构建系统”与我选择的 VCS 集成不会像 CheeseShop 源代码压缩包（或鸡蛋）那样运行，上帝保佑）。这就是我在这种情况下寻找对 distutils 友好的解决方案的原因。

好的，既然你在鼓励我，我会快速尝试说服你哈哈哈......你希望构建系统不依赖于 VCS，这样用户就可以破解并在不需要 VCS 的情况下构建模块。既然您使用的是 git，那么用户在不使用 git fork 的情况下破解您的模块是否真的有意义，从而具有提交钩子的能力？那不是鼓励一种不好的做法吗？此外，用户需要安装一个 coffescript 编译器来使用他的修改来构建你的模块，这意味着他应该有足够的能力使用 git fork 和 hooks。快速尝试，选择是你的

哈哈哈——关于练习的事情是：你必须练习它们。因为通常情况下，最佳实践有益于程序员qua更大的生态系统。 Distutils 就是一个很好的例子：它是为了最终用户的利益，我们都喜欢讨厌它；但归根结底，安装某些东西的 Pythonic 方式是使用pip install something——作为最终用户，当我安装别人的包时，我更喜欢这样，而不是用一个装满神秘代码。这个级别的用户可能相当称职，但如果我测试他们的能力，他们会不愿意使用我的东西。