workingenv.py 0.6.5

安装

您不需要将其作为Python包安装；您可以简单地 下载脚本 并运行它。这避免了将内容安装到您的环境中以便开始设置环境时的鸡生蛋问题。

您也可以使用 easy_install workingenv.py 安装它，无需setuptools（它不依赖于setuptools进行安装），或使用 easy_install workingenv.py==dev 从 subversion存储库 安装。

摘要

此工具创建一个与Python安装的其他部分隔离的环境，消除了site-packages和其他模块源，因此只有您安装到环境中的模块（和版本）才可用。这允许创建隔离和受控的环境，以及可重复性。这与 virtual-python 类似，但没有符号链接并具有一些附加功能。

基本用法是

$ python workingenv.py MyNewEnvironment
$ source MyNewEnvironment/bin/activate

在执行 bin/activate 后，任何命令（如 python setup.py install 等）都将安装到新环境中。同时，也会为该环境生成一个 Windows 的 activate.bat 文件。像 bin/easy_install 这样的脚本将与环境绑定，因此即使没有激活，它们也会自动安装到环境中。

更改

0.6.5：导出 $_WE_OLD_WORKING_PATH 等。激活新环境时，也会使环境失效。在该平台上包含 Darwin Ports site-packages 目录。-env 之前被完全忽略；现在正常工作。

0.6.4：使用 --always-unzip 与 ez_setup.py，以免有时（在 Python 2.5？）将 setuptools 安装为 egg 格式。在 activate.bat 中不要将环境变量加引号。打印出具有嵌套的安装信息，以显示哪些库通过哪些库拉取了依赖关系。

0.6.3：当 cli|gui.exe 缺失时，不要引发异常。在 distutils.cfg 中设置 always_copy = True，以避免与系统范围内的包有关的一些问题。在 Setuptools 安装期间显示一些进度指示。

0.6.2：除了使用工作环境特定的 distutils.cfg 之外，还使用系统 distutils.cfg；这有助于获取系统范围内的编译器设置。修复在 Windows 上创建命令行脚本的问题（缺少 cli.exe 或 gui.exe）。

0.6.1：小的错误修复，同时 Windows 的 activate.bat 文件现在会更改提示（来自 Patrick O’Brien）。另外，安装脚本作为 workingenv，以避免与模块冲突。

0.6：从 –requirements 文件中拉取依赖关系，不管当前激活的环境是否可能提供这些依赖关系。包括一个 setup.py 文件。不打印来自 ez_setup.py 和 easy_install 的无聊消息。

0.5：修复脚本的自我激活。

0.4：修复 --site-packages 选项（引入全局 site-packages/ 目录）与全局 setuptools 安装的交互。如果您收到类似于“site.py 不是由 setuptools 生成的 site.py；请删除它”的错误，您应该升级并重新生成您的 workingenv。

0.3：支持 Setuptools 0.6c5

激活

当您“激活”环境时，python 将将此环境视为唯一的 Python 环境。它是通过设置 $PYTHONPATH 并覆盖标准的 site.py 来做到这一点的。

使用“setup.py install”和 easy_install 的安装将进入正确的位置。使用 easy_install（不是其他方式）构建的脚本将与环境绑定，即使脚本运行时环境未激活。

激活本身意味着将 lib/python2.4/ 添加到 $PYTHONPATH。如果您不想使用 bin/activate，只需这样做：

$ export PYTHONPATH=”WORKINGENV/lib/python2.4” $ <使用 Python 的任何内容>

bin/activate 还会更新您的提示并将 $PATH 设置为指向 workingenv 的 bin/。这没有其他魔法，因此如果您想的话，可以通过这种方式复制相同的功能。（注意，bin/activate 会更改您的环境，这就是为什么它必须被 source 到 shell 环境中。）

有关初始讨论，请参阅此帖子。讨论应发送到 distutils-sig@python.org。

要求

还包括了一组需求的概念，因此您可以启动一个完整的包集。这是一个包含可安装需求的文本文件，每行一个。该文件还可以包含 -r other_file 和 -f place_to_find_packages。使用它，您可以向用户/开发者提供非常具体的工作包集。您还可以在需求前使用 -e 将该需求安装到 src/ 开发模式中。

提供了两个这种需求示例，“tg-example.txt” 和 “tg-0.9.txt”。请注意，将这些放入单独的文件中，在测试后调整需求时，不需要更改任何特定包的需求。这样，您可以提供非常精确的需求，并且以后可以根据升级调整这些需求，而不会导致任何包不稳定。

重新生成环境

环境携带它们创建时的设置（在 .workingenv/ 中）。这使得您可以再次运行 workingenv.py ENVIRONMENT 以进行更新，并且设置将仍然保留。

在覆盖任何文件之前，您将需要确认更改。您还可以使用 --simulate 来查看它 将会 做什么。

Windows

workingenv 应该在 Windows 上工作，但在启动脚本之前必须使用 activate.bat – 它们无法在 Windows 上自行激活。

Zope

workingenv.py 将 与 Zope 2 一起工作，但您应该使用 –home 选项（这将所有内容放入 lib/python/ 而不是 lib/python2.4/）。Zope 和许多 Zope 产品就是这样设置的，它们期望这种布局。

以编程方式使用workingenv

您可以像脚本一样使用 workingenv.main()；这可能是编程使用它的最佳/最安全的方式。当然，在子进程中调用它也会工作。