我正试图将整个PPA包裹起来,这似乎是不必要的困难,因为每个人都想成功。让我们看一个像http://bokeh.pydata.org/这样的项目,它有一个node.js依赖项并从中生成一个.deb。关注this guide以及此处的各种帖子后,我尝试使用stdeb
来执行此操作:
pypi-download bokeh
tar xfz bokeh-0.7.0.tar.gz
cd bokeh-0.7.0/bokehjs/
npm install
grunt build
cd ..
python3 setup.py --command-packages=stdeb.command sdist_dsc
输出的结尾是
dh clean --with python3 --buildsystem=python_distutils
dh_testdir -O--buildsystem=python_distutils
debian/rules override_dh_auto_clean
make[1]: Entering directory `/home/emre/Desktop/bokeh-0.7.0/deb_dist/bokeh-0.7.0'
python3 setup.py clean -a
/home/emre/Desktop/bokeh-0.7.0/deb_dist/bokeh-0.7.0/bokehjs
ERROR: Cannot install BokehJS: files missing in `./bokehjs/build`.
Please build BokehJS by running setup.py with the `--build_js` option.
Dev Guide: http://bokeh.pydata.org/docs/dev_guide.html#bokehjs.
我就这么做了!我错过了什么吗?这个建筑物甚至是直接用于pypi的东西所必需的吗?指南掩盖了这些事情。
答案 0 :(得分:1)
制作好的deb可能很复杂,是的,特别是当你不是上游作者并且不确定他们对软件安装的意图时。复杂性是必要的,因为良好行为的deb必须符合相当长的policies和requirements列表,以便用户知道在许多不同情况和情况下对它们的期望。 debs的来源需要包含足够的信息,可以通过自动化系统构建(包括安装任何必要的构建依赖项)。二进制(内置)debs必须将其文件放在系统上的正确位置,而不是破坏任何其他软件包,并且能够在完全卸载后自行清理。在没有用户在交互式终端上观看的情况下,可以安装Debs。 Debs必须声明它们的所有依赖项以及这些依赖项的必要版本,除了一些被认为是“必需”的包。在构建或安装期间,Debs不应从Internet下载任何内容。等等等等。这种严格程度以及社区遵守的程度实际上是运行基于Debian的发行版的最重要的好处之一。
另一方面,Python源代码分发(例如你在PyPI上找到的那些)几乎可以做任何他们想做的事情。有setup.py
构建和安装命令的新兴最佳实践,但它们并不总是被遵循,即使它们存在,仍然有很大的解释和差异空间。某些内容(例如您在此引用的内容)可能会随意要求用户在正常构建之前使用不同的非标准选项调用setup.py
。一些人继续下载他们自己的依赖项并将它们放在他们想要的任何地方。除了琐碎的大多数软件包都不知道如何卸载自己。
这两种方法都很好,在不同的情况下更好。但希望您现在可以看到为什么在一般情况下不可能将任意Python源代码分发自动转换为工作deb。计算机必须假设Python的行为方式太多了。
说了这么多,如果你不关心是否符合Ubuntu / Debian政策并且你只想将某些内容存放在个人存储库中,那么最简单的方法就是更改Python源代码,以便它会根据需要自动执行--build_js
事件,而不是抱怨并要求用户执行此操作。