在 Python 3 中捆绑第三方库进行分发的最佳实践
我正在使用 Python 3 开发应用程序。使用第三方库进行开发过程和最终用户分发的最佳实践是什么？请注意，我正在这些限制范围内工作：
- 团队中的开发人员应该拥有完全相同版本的库。
- 理想的解决方案可以同时在 Windows 和 Linux 上运行。
- 我想避免让用户在使用我们自己的软件之前安装软件；也就是说，他们在使用我们的产品之前不必安装产品 A 和产品 B。
I'm developing an application using Python 3. What is the best practice to use third party libraries for development process and end-user distribution? Note that I'm working within these constraints:
- Developers in the team should have the exact same version of the libraries.
- An ideal solution would work on both Windows and Linux.
- I would like to avoid making the user install software before using our own; that is, they shouldn't have to install product A and product B before using ours.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
您可以使用 setuptools 为您的库创建 Egg 文件，假设它们不以 Egg 形式提供已经。然后，您可以将鸡蛋与您的软件捆绑在一起，这需要安装它们，或者确保它们位于导入路径上。
这有一些复杂性，即如果你的库有 C 扩展，那么你的鸡蛋就会变得特定于平台，但根据我的经验，这是 Python 中最广泛接受的“捆绑”内容的方法。
但我不得不说，这仍然是 Python 的弱点之一；第三方生态系统当然是针对开发者而不是最终用户。
You could use setuptools to create egg files for your libraries, assuming they aren't available in egg form already. You could then bundle the eggs alongside your software, which would need to either install them, or ensure that they were on the import path.
This has some complexities, i.e. if your libraries have C-extensions, then your eggs become platform-specific, but in my experience this is the most widely-accepted means of 'bundling' stuff in Python.
I have to say that this remains one of Python's weaknesses, though; the third-party ecosystem is certainly aimed at developers rather than end-users.
没有最佳实践，但人们遵循一些不同的轨道。对于商业产品分发，有以下几种：
管理您自己的软件包服务器
对于您的开发过程，通常是从本地更新您的开发盒包服务器。这允许您“冻结”依赖项列表（即停止获取上游更新），以便每个人都使用相同的版本。您可以在特定时间进行更新，也可以让开发人员进行更新，从而使每个人保持同步。
对于客户安装，您通常会编写安装脚本。您可以收集所有软件包并安装您的库，同时安装其他库。尝试安装新的 Python，甚至任何标准库都可能会出现问题，因为客户可能已经依赖于不同的版本。通常，您可以安装在沙箱中，以将您的软件包与系统软件包分开。这个问题在 Linux 上比 Windows 上更严重。
工具链
另一个选项是为每个支持的操作系统创建一个工具链。工具链是所有依赖项（最多但不包括像 glibc 这样的基本操作系统库）。该工具链被打包并分发给开发人员和客户。工具链的最佳实践是：
.../bin目录中以防止意外使用。 （即，在 Linux 上，您可以安装在.../libexec下。/opt也可以使用，尽管我个人讨厌它。）.../libexec下的正确位置。 code>lib/python/site-packages 所以你不必使用 PYTHONPATH。.py文件，以便安装脚本可以适当地重新定位它们。There are no best practices, but there are a few different tracks people follow. With regard to commercial product distribution there are the following:
Manage Your Own Package Server
With regard to your development process, it is typical to either have your dev boxes update from a local package server. That allows you to "freeze" the dependency list (i.e. just stop getting upstream updates) so that everyone is on the same version. You can update at particular times and have the developers update as well, keeping everyone in lockstep.
For customer installs you usually write an install script. You can collect all the packages and install your libs, as well as the other at the same time. There can be issues with trying to install a new Python, or even any standard library because the customer may already depend on a different version. Usually you can install in a sandbox to separate your packages from the systems packages. This is more of a problem on Linux than Windows.
Toolchain
The other option is to create a toolchain for each supported OS. A toolchain is all the dependencies (up to, but not including base OS libs like
glibc). This toolchain gets packaged up and distributed for both developers AND customers. Best practice for a toolchain is:.../bindirectories to prevent accidental usage. (ie. on Linux you can install under.../libexec./optis also used although personally I detest it.)lib/python/site-packagesso you don't have to use PYTHONPATH..pyfiles for the executables so the install script can relocate them appropriately.