Python部署的最佳实践——多版本、标准安装位置、打包工具等
关于这个问题的不同方面的许多帖子，但我还没有看到将所有这些内容结合在一起的帖子。
首先是一个主观的陈述：当我们移出解释器并开始解决部署问题时，我们在使用 Python 语言时所体验到的简单性似乎就被打破了。如何最好地在同一台机器上安装多个版本的Python？软件包应该安装在哪里？ Disutils、setuptools、pip 等。在部署方面，Python 之禅似乎被滥用得相当严重。我感受到了 Windows 上“DLL 地狱”体验的怪异回响。
<块引用>专家们是否就这些问题达成某种程度的最佳实践？
你是否在同一台机器上运行多个版本的Python？您如何保持对它们可以共存的信心 - 并且新版本不会破坏依赖于早期版本的其他进程（例如，操作系统供应商提供的脚本）的假设？这安全吗？ virtualenv 够用吗？
Python 环境的不同组件（包括第 3 方包）在本地文件系统上的最佳位置选择是什么？许多不同版本的 Unixy 和 Windows 操作系统的位置之间是否存在可以信赖的严格或粗略的对应关系？
还有沼泽中最阴暗的角落——你使用什么安装工具（setuptools、distutils、pip 等），它们是否能很好地配合你的选择：文件位置、Python 虚拟环境、Python 路径等。
这些听起来像是难题。我希望经验丰富的 Pythonista 可能已经定义了应对这些挑战的规范方法（或两种）。任何“悬挂在一起”作为一个可以放心使用的系统（感觉不像单独的、不相关的工具）的方法都会非常有帮助。
Many posts on different aspects of this question but I haven't seen a post that brings it all together.
First a subjective statement: it seems like the simplicity we experience when working with the Python language is shot to pieces when we move outside the interpreter and start grappling with deployment issues. How best to have multiple versions of Python on the same machine? Where should packages be installed? Disutils vs. setuptools vs. pip etc. It seems like the Zen of Python is being abused pretty badly when it comes to deployment. I'm feeling eerie echoes of the "DLL hell" experience on Windows.
Do the experts agree on some degree of best practice on these questions?
Do you run multiple versions of Python on the same machine? How do you remain confident that they can co-exist -- and the newer version doesn't break assumptions of other processes that rely on the earlier version (scripts provided by OS vendor, for example)? Is this safe? Does virtualenv suffice?
What are the best choices for locations for different components of the Python environment (including 3rd party packages) on the local file system? Is there a strict or rough correspondence between locations for many different versions of Unixy and Windows OS's that can be relied upon?
And the murkiest corner of the swamp -- what install tools do you use (setuptools, distutils, pip etc.) and do they play well with your choices re: file locations, Python virtual environments, Python path etc.
These sound like hard questions. I'm hopeful the experienced Pythonistas may have defined a canonical approach (or two) to these challenges. Any approach that "hangs together" as a system that can be used with confidence (feeling less like separate, unrelated tools) would be very helpful.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我发现 virtualenv 是在同一台计算机上配置和维护多个环境的唯一可靠方法。它甚至可以作为打包环境并将其安装在另一台计算机上的一种方式。
对于包管理，我总是使用 pip 因为它与 virtualenv 配合得很好。它还可以轻松地从各种来源（例如 git 存储库）安装和升级软件包。
I've found that virtualenv is the only reliable way to configure and maintain multiple environments on the same machine. It even has as a way of packaging up environment and installing it on another machine.
For package management I always use pip since it works so nicely with virtualenv. It also makes it easy to install and upgrade packages from a variety of sources such a git repositories.
我同意这是一个相当广泛的问题，但无论如何我都会尝试解决它的许多部分。
关于你的主观陈述：我不明白为什么Python的简单和优雅会意味着打包和部署问题突然应该变得简单。与包装相关的有些事情很简单，有些则不然，有些可能很简单。如果我们拥有一个完整、强大且简单的包装系统，那对用户来说是最好的，但事实并没有这样。 distutils 被创建，然后它的开发暂停，setuptools 被创建并添加了新的解决方案和新问题，distribute 由于社会问题而从 setuptools 中分叉出来，最后创建了 distutils2 来制作一个正式的完整库。 （更多关于distribute、distutils、setuptools和distutils2之间的差异？）对于开发人员和用户来说远非理想，但我们正在努力使其变得更好。
如何最好地在同一台机器上安装多个版本的Python？如果您使用的是现代操作系统，请使用包管理器；如果您在 UNIX 上从源代码编译，请使用“make altinstall”；如果您在 Windows 上从源代码编译，请使用类似的非冲突安装方案。作为 Debian 用户，我知道我可以使用“pythonX.Y”来调用各个版本，而默认版本（“python”和“python3”）是由 Debian 开发人员决定的。一些操作系统已经开始打破 python == python2 的假设，因此正在开发一个 PEP 来祝福或谴责这一点： http://www.python.org/dev/peps/pep-0394/ Windows 似乎缺乏一种使用一个 Python 版本作为默认版本的方法，因此还有另一个 PEP： http://www.python.org/dev/peps/pep-0397/< /a>
软件包应该安装在哪里？使用 distutils，我可以将项目安装到我的用户 site-packages 目录中（请参阅 PEP 370 或 docs.python.org）。问题到底是什么？
不支持同一项目的不同版本的并行安装。需要一名 PEP 来讨论导入系统和打包工具的更改。在有人开始讨论之前，使用 virtualenv 或 buildout 就足够好了。
我不明白有关“Python环境的组件”位置的问题。
我主要使用系统软件包（即在 Debian 上使用 Aptitude 软件包管理器）。为了尝试项目，我克隆了他们的存储库。如果我需要 Aptitude 无法提供的东西，我会在我的用户 site-packages 目录中安装（或将 .pth 文件放入存储库）。我不需要自定义 PYTHONPATH，但我已使用 PYTHONUSERBASE 更改了用户站点包的位置。我不喜欢 setuptools/distribute 中的魔法和鸡蛋概念，所以我不使用它们。我已经开始在一个项目中使用 virtualenv 和 pip （他们在幕后使用 setuptools，但我进行了私人安装，所以我的全局 Python 没有 setuptools）。
I agree this is quite a broad question, but I’ll try to address its many parts anyway.
About your subjective statement: I don’t see why the simplicity and elegance of Python would imply that packaging and deployment matters suddenly should become simple things. Some things related to packaging are simple, other are not, other could be. It would be best for users if we had one complete, robust and easy packaging system, but it hasn’t turned that way. distutils was created and then its development paused, setuptools was created and added new solutions and new problems, distribute was forked from setuptools because of social problems, and finally distutils2 was created to make one official complete library. (More on Differences between distribute, distutils, setuptools and distutils2?) The situation is far from ideal for developers and users, but we are working on making it better.
How best to have multiple versions of Python on the same machine? Use your package manager if you’re on a modern OS, or use “make altinstall” if you compile from source on UNIX, or use the similar non-conflicting installation scheme if you compile from source on Windows. As a Debian user, I know that I can call the individual versions by using “pythonX.Y”, and that what the default versions (“python” and “python3”) are is decided by the Debian developers. A few OSes have started to break the assumption that python == python2, so there is a PEP in progress to bless or condemn that: http://www.python.org/dev/peps/pep-0394/ Windows seems to lack a way to use one Python version as default, so there’s another PEP: http://www.python.org/dev/peps/pep-0397/
Where should packages be installed? Using distutils, I can install projects into my user site-packages directory (see PEP 370 or docs.python.org). What exactly is the question?
Parallel installation of different versions of the same project is not supported. It would need a PEP to discuss the changes to the import system and the packaging tools. Before someone starts that discussion, using virtualenv or buildout works well enough.
I don’t understand the question about the location of “components of the Python environment”.
I mostly use system packages (i.e. using the Aptitude package manager on Debian). To try out projects, I clone their repository. If I need something that’s not available with Aptitude, I install (or put a .pth file to the repo) in my user site-packages directory. I don’t need a custom PYTHONPATH, but I have changed the location of my user site-packages with PYTHONUSERBASE. I don’t like the magic and the eggs concept in setuptools/distribute, so I don’t use them. I’ve started to use virtualenv and pip for one project though (they use setuptools under the cover, but I made a private install so my global Python does not have setuptools).
该领域的资源之一是 Tarek Ziade 所著的《Expert Python Programming》一书。我对这本书的质量很矛盾，但所涵盖的主题正是你所关注的。
One resource for this area is the book Expert Python Programming by Tarek Ziade. I'm ambivalent about the quality of the book, but the topics covered are just what you're focusing on.