不久前我写了关于将模块安装到自定义位置的文章，在那篇文章中，我说不在虚拟环境中这样做的一个原因是，我不想为了使用一些 Python 模块而将涉及的程序放到虚拟环境中。最近我意识到，你不必这样做，因为虚拟环境是如何将自己添加到sys.path 。 只要你使用虚拟环境的 Python 运行你的程序，它就可以使用你安装在 venv 中的所有模块。程序在哪里并不重要，你也不需要把它从当前的位置移开，你只需要改变它使用的 'python'。
这个的完整扩展版本是，如果你的程序被设置为使用 '#!/usr/bin/env python3' 运行，你可以改变Python，从而改变你使用的虚拟环境，只需改变它使用的$PATH 。这样做的缺点是，你可能会意外地使用与你预期不同的 Python，因为你的$PATH 并没有按照你所想的方式设置，尽管在很多情况下，这将导致直接和明显的问题，因为你预期的一些模块不在那里。
(一种可能发生的情况是，如果你使用系统的 Python 运行程序，因为你用默认的$PATH 启动它。一种经典的方式是通过 crontab 条目运行事情。)
另一个可能的用途，特别是在基于$PATH 的版本中，是用新的、更新的模块组装一个新的虚拟环境，以便用它们测试你现有的程序。你也可以用它在实时使用中来回切换模块版本，只需改变你的程序运行的$PATH （或者通过反复编辑它的#! 行，但那是更多的工作）。
意识到这一点，我在未来更有可能只为第三方模块使用虚拟环境。剩下的一个令人恼火的问题是，虚拟环境是特定于Python版本的，但有各种方法来处理这个问题。这是我认为我们要使用 'pip freeze' (提前)，然后在新的虚拟环境中完全重现我们之前的安装的情况之一。或者我们可以让'python3 -m venv --upgrade <venv-dir>'工作，尽管我不打算在这个问题上屏住呼吸。
(一个快速的测试表明，升级虚拟环境不起作用，至少从Ubuntu 18.04 LTS Python 3到Ubuntu 20.04 LTS Python 3不起作用。这或多或少是我所期望的，考虑到会涉及到的问题，所以就从头开始建立一个新的虚拟环境。我不能说我对虚拟环境的这种限制特别满意，特别是考虑到我们总是有至少两个版本的Python 3在身边，因为我们总是有两个版本的Ubuntu LTS在使用。)
