7

我已经在使用 pip 和 virtualenv（实际上有时仍然更喜欢通过 SVN 存储库进行组织良好的组合，明智地使用 svn:externals 和动态 sys.path）。

但是这次对于新的服务器安装，我想以正确的方式做事。

所以我去了pip 安装页面，它说：

使用 pip 的推荐方法是在 virtualenv 中，因为每个 virtualenv 都自动安装了 pip。这不需要 root 访问权限或修改您的系统 Python 安装。[...]

然后我转到virtualenv 安装页面，它建议：

您可以使用 pip install virtualenv 安装 virtualenv，或者使用 pip install virtualenv==dev 安装最新的开发版本。您还可以使用 easy_install [...]

当然，pip 应该取代easy_install :)

当然，他们都解释了所有替代的安装方式。

但是……应该先走哪一个？ 我是否应该支持系统范围的点子？

我看到一个需要思考的主要原因，但可能还有其他原因

  • 我是否想为该盒子的所有用户提供便利，或者这是一个针对运行某些服务的单个用户的服务器？

如果我希望每个人都有一个可用的虚拟环境，我可能只安装一个系统范围的 pip（例如，使用 ubuntusudo aptitude install python-pip然后使用它来安装 virtualenv sudo pip install virtualenv）。

编辑另一个需要考虑的原因：virtualenvwrapper安装说明（但不是文档）说：

注意 为了使用 virtualenvwrapper，您必须单独安装 virtualenv。

不完全确定“单独”是什么意思（我从未注意到）。

否则，应该先走哪一个，这真的有影响吗？

有关的：

最接近的问题（和答案）是以下第一个（特别是参见@elarson 答案），第二个看起来过于复杂：

但我觉得这一切都无法完整地回答我的问题：系统范围与本地，但 pip 或 virtualenv 也应该先行（以及为什么他们将每个人发送给另一个人开始！！！）

4

3 回答 3

6

tl; dr 首先是 VirtualEnv。对于 Python 版本 2.x 和 3.x，您可以分别拥有两个

[编辑]

我真的很怀疑安装（没有安装，您只需下载并执行脚本） VirtualEnv 系统范围/每个用户是否重要。使用 VirtualEnv 的全部意义在于创建隔离的开发沙箱，以便一个项目中的库不会相互冲突。例如，您可以在两个不同的虚拟环境中使用 Beautiful-soup Version < 4.x 的 Python 2.x 项目和使用 Beautiful-soup 4.0 版的 Python 3.x 项目。

如何在系统上获取 VirtualEnv 脚本并不重要，因为一旦你拥有它并且 pip 是自包含在 VirtualEnv 中的，那么首先获取 VirtualEnv 就很有意义。同样，一旦您使用 python，您将拥有许多项目，并且对于每个项目，推荐的方法是拥有一个虚拟环境，然后通过 pip 安装依赖项。您可以稍后执行“pip freeze > requirements.txt”，然后执行“pip install requirements.txt”，以简单地在两个系统中复制您的确切库[比如开发和生产]等等......

于 2012-05-09T15:46:55.570 回答
1

半个，六打另一个。（让它沉入水中。哈哈。）

但更严重的是，您的系统上真的有多个用户吗？如今，即使是 Linux 主机也倾向于为单个用户服务，并且在有多个用户 ID 的情况下，它们往往是在各种隔离用户 ID 下运行多个进程的服务器。鉴于此，让所有用户的生活更轻松并不是那么重要。

另一方面，每个使用 Python 的多个服务可能有相互冲突的要求，这种情况很少见，因为它甚至可以归结为所需的pip. 鉴于此，我倾向于更喜欢 virtualenv 的全局安装，以便进行 Python 的原始准安装。

然而，我想指出另一个想法：Buildout，http ://www.buildout.org/

Buildout 与 virtualenv 做同样的事情，但采用了截然不同的方法。您编写一个构建配置文件 ( buidout.cfg)，列出您的各种鸡蛋是什么以及它们将如何连接，并指定设置特殊情况的“构建配方”设置（如 Django 部署、Buildbot 服务器、Plone 网站， Google 应用引擎应用等）。

然后你使用你的系统 Python 来引导构建，运行它，它会生成一个独立的设置——就像一个 virtualenv。

但最好的部分是：它是可重复的。您可以将其buildout.cfg带到另一台主机并获得相同的设置。使用 virtualenv更难做到这一点！

于 2012-05-09T15:38:39.797 回答
1

尚未决定最终的解决方案，但这就是现在正在发生的事情，部分基于@nutjob 评论（不，我暂时没有切换到 buildout，但我稍后会花一些时间！）

我有一个大而强大的服务器，里面有很多 django 应用程序。我主要使用 gunicorn + supervisord。

这些要求规定了以下内容，但稍有不同的设置可能会有所不同。

  1. 基于代码/功能的相似性，我将这些应用程序逻辑地组织在集群中；每个集群都可能有相同版本的常用 python 库（pylibmc、pillow 等）
  2. 我创建了几个用户，每个集群一个
  3. 对于每个用户，我通过下载 virtualenv.py 并运行来安装 virtualenv（与用户同名，由我自己选择）python virtualenv.py VIRTUALENVNAME；我没有安装 virtualenv 包装器
  4. 我编辑该用户 .bashrc 以便立即加载 virtualenv
  5. 我使用 pip 安装常用包，但更具体的包是通过 sys.path 直接添加的。这使我能够更快地部署，因为文件夹/版本控制项目结构在那里承载了所有大多数必需的库。我发现这更清晰，部署更快，更容易编辑。您的个人案例的里程可能会有所不同。

这意味着每个用户都有自己的单个 virtualenv。

如果我从头开始，我可能会转向构建或类似的解决方案（我不喜欢混合主管和 virtualenv 时会发生什么），但我现在对这个很满意......

于 2012-05-15T15:32:30.620 回答