2011-04-21 144 views
8

我正在开发使用Python 3,什么是用于开发过程和最终用户分发第三方库的最佳实践的应用程序?请注意,我在以下约束条件下工作:最佳实践3

  • 团队中的开发人员应该具有完全相同的库版本。
  • 理想的解决方案可以在Windows和Linux上运行。
  • 我想避免让用户在使用我们自己的软件之前安装软件;也就是说,在使用我们的产品之前,他们不应该安装产品A和产品B.
+0

我有这个问题出现。我正在用Python构建一个raytracer,并且我依靠PIL编写图像。当我将它移到Mac上时,它完全打破了我的光线追踪器,因为Apple不会在Mac OS中装运PIL。如果你不使用这个库,请考虑摆脱它并编写自己的解决方案。 – Blender 2011-04-21 15:31:03

回答

1

有没有最佳实践,但也有一些不同的轨道人们遵循。关于商业产品分布有以下几点:

管理自己的包服务器

关于你的发展过程中,这是典型的要么有你的dev的框更新从本地包服务器。这允许您“冻结”依赖列表(即停止获取上游更新),以便每个人都处于相同版本。您可以在特定时间进行更新,并让开发人员进行更新,让每个人都保持同步。

为客户安装你平时写的安装脚本。您可以收集所有软件包并同时安装您的库和其他库。尝试安装新的Python,甚至任何标准库都可能存在问题,因为客户可能已经依赖于不同的版本。通常,您可以安装在沙箱中以将软件包与系统软件包分开。这在Linux上比在Windows上更成问题。

工具链

另一种选择是创建工具链为每个支持的操作系统。工具链是所有的依赖项(最多但不包括基本操作系统库,如glibc)。该工具链被打包并分发给开发者的客户。工具链的最佳做法是:

  • 更改可执行文件以防止混淆。 (即python - > pkg_python)
  • 请勿安装在.../bin目录中以防止意外使用。 (即在Linux上,你可以安装在.../libexec,/opt也可以使用,尽管我个人很讨厌它)。
  • 将你的库安装在lib/python/site-packages的正确位置,所以你不必使用PYTHONPATH。
  • 为可执行文件分配源.py文件,以便安装脚本可以适当地重新定位它们。
  • 封装格式应该是操作系统本地程序包(红帽 - > RPM,Debian的 - > DEB,赢 - > MSI)
0

假设第三方库可以从PyPI中,使用的distutils,并指定在setup.py所需的版本。

+0

恩,谢谢,但它违反了我列表中的#3。假设客户端没有互联网连接。 – Dewfy 2011-04-21 15:53:17

+0

如果用户可能没有互联网连接,解决方案很简单。显然,如果不捆绑所有可能需要的库,就无法解决问题。 – geoffspear 2011-04-21 15:56:08

+0

打包+1。不过,我不确定图书馆是否希望你这样做。 – Blender 2011-04-21 16:03:59

1
+0

嗯,谢谢,但它违反了我列表中的#1,#3。假设客户端没有互联网连接。开发者应该始终采用固定版本(???可能是SVN仓库) – Dewfy 2011-04-21 15:54:06

+0

我建议不要将第三方模块放到你自己的SVN仓库中,特别是如果你正在开发和测试跨平台,因为它们需要以不同的方式进行编译。至于@ vartec的建议不符合您的要求,我认为您错了。需求文件可以指定该模块的模块和版本,因此可以精确地满足您的需求。如果您在自己的项目中嵌入了其他项目,请确保您没有违反任何许可条款。 – 2011-04-21 16:21:43

+0

@StephenPaulger - 我们的项目是作为源代码发布的,所以没有违规包含另一个LGPL库源。你已经抓住了我的问题的主要事情,但它仍然打开。嵌入3D派对的正确技术解决方案是什么? – Dewfy 2011-04-21 16:32:08

3

您可以使用setuptools为您的库创建蛋文件,假设它们不是蛋形式的可用文件。然后,您可以将鸡蛋与软件捆绑在一起,这需要安装它们,或确保它们位于导入路径上。

这具有一定的复杂性,也就是说,如果你的图书馆有C-扩展,那么你的鸡蛋成为特定于平台的,但在我的经验,这是在Python“捆绑”的东西最广泛接受的手段。

我不得不说,这仍然是Python的弱点之一,虽然;第三方生态系统肯定是针对开发者而不是最终用户。

+0

高度赞同您最终用户的弱点。我发现很多麻烦都提出了一种清晰的系统化方法来构建软件工具和流水线,这对基于Windows的最终用户在向他们交付软件时毫不费力。 – 2013-11-28 16:23:33