根据Linux文件系统层次结构标准，将Python虚拟环境放在哪里合适？

Question

正如标题所问，根据linuxfhs，在Linux操作系统上存储Python虚拟环境在技术上合适的位置是什么？在

提出了另一种明确答案的方法：将Python虚拟环境的位置与所服务的数据文件分开“技术上正确”吗？在

注意：This question differs from the closest, already-asked question I could find，因为虚拟环境包含库、二进制文件、头文件和脚本。在

另外，我倾向于编写支持internet访问服务的代码。但是，我认为这并没有将我的需求与服务的使用者是同一服务器上的其他进程的场景有实质性的区别。我提到这一细节，以防我对评论的回应包括“web开发”式的内容。在

作为参考，我使用以下文档作为我对linuxfhs的定义：http://www.pathname.com/fhs/pub/fhs-2.3.html

我不相信流行的virtualenv包装器脚本建议正确的操作，因为它默认将虚拟环境存储在用户的主目录中。这违反了目录是用于用户特定文件的隐式概念，以及“任何程序都不应依赖于此位置”的语句

在文件系统的根级别，我倾向于使用^{}（可共享的只读数据）或{a4}（此系统提供的服务的数据），但这是我很难进一步决定的地方。在

如果我支持我的转到反向代理的决定，那意味着^{}。Nginx通常被打包成/usr/share/Nginx或/usr/local/Nginx，但是，/usr/应该是mounted read-only according to the FHS。我觉得这很奇怪，因为我从来没有参与过一个项目，在这个项目中，开发进度太慢，以至于“以只读方式卸载/使用write重新装载，以只读方式卸载/重新装载”被认为是值得的。在

^{}是另一个可能的位置，但被称为“特定服务的数据文件的位置”，而Python虚拟环境更关注于提供服务的库和二进制文件（如果没有这种区别，.so文件也将在srv中）。另外，具有相同需求的多个服务可以共享一个虚拟环境，这违反了描述的“特定”细节。在

我认为选择正确位置的部分困难是因为虚拟环境是一个“环境”，它包括二进制文件和库（几乎就像它自己的小层次结构），这使我觉得/usr下面的某个地方更传统：

virtual-env/
├── bin          ~= /usr/local : "for use by the system administrator when installing software locally" 
├── include      ~= /usr/include : "Header files included by C programs"
├── lib          ~= /usr/lib : "Libraries for programming and packages"
└── share        ~= /usr/local

根据我的假设和想法：考虑Nginx作为Python应用程序的反向代理的常见场景。它是一个虚拟的源代码环境。应用程序.py)在/usr/local/service_name/下使用/srv来处理经常更改的文件（例如“静态”资产、图像、css）？在

编辑：需要澄清的是：我知道为什么和如何使用virtualenvs。我对项目布局和在开发环境中工作一点也不困惑。在

Answer 1

As the title asks, what is the technically proper location to store Python virtual environments on Linux operating systems according to the Linux FHS?

请记住，Linux FHS不是一个真正的标准，它是一组指导原则。它只被LSB称为一个标准，LSB只是一堆规则，使支持Linux变得更容易。在

/run、/sys、/proc和{}都不是LFS的一部分，但是在大多数linux发行版中可以看到它们。在

对我来说，放置虚拟环境的明确选择是/opt，因为这个位置是reserved for the installation of add-on software packages。在

然而，在大多数Linux发行版中，只有root用户可以写入/opt，这使得这是一个糟糕的选择，因为虚拟环境的主要目标之一是避免成为root用户。在

因此，我推荐/usr/local（如果它可以由您的普通用户帐户写入），但是在您的主目录中安装它没有任何问题。在

Stated another way that allows for a clear answer: Is it "technically correct" to separate the location of a Python virtual environment from the data files you are serving?

我不知道您所说的“您正在服务的数据文件”是什么意思，但以下是虚拟环境的规则：

1. 不要把它们放在源代码管理中。在
2. 维护一个installed packages列表，并将这个放入版本控制中。请记住，虚拟环境并不完全是可移植的。在
3. 将虚拟环境与源代码分开。在

鉴于上述情况，您应该将虚拟环境与源代码分开。在

consider the common scenario of Nginx acting as a reverse proxy to a Python application. Is it correct to place a virtual environment and source code (e.g. application.py) under /usr/local/service_name/ while using /srv for more dynamic files (e.g. 'static' assets, images)?

静态资产不是动态文件，我认为你是混淆术语。在

无论哪种方式，您都应该执行以下操作：

1. 创建一个用户帐户来运行该应用程序。在
2. 将应用程序文件放在由该用户和该用户单独控制的目录下。通常这是/home/username目录，但您可以将其设为/services/servicename。以标准命名格式将虚拟环境作为此目录的一个子集。例如，我使用env。在
3. 将静态资产（如所有媒体文件、css文件等）放在前端服务器可读的目录中。因此，通常您将创建一个www目录或public_html目录。在
4. 请确保为此应用程序创建的用户帐户具有对此资产目录的写访问权限，以便能够更新文件。代理服务器不应对此目录具有执行权限。您可以通过将目录组更改为与代理服务器用户组相同的组来完成此操作。鉴于此，我将把这个目录放在/home/username/或{}下。在
5. 使用流程管理器启动应用程序，并确保流程管理器在运行应用程序代码时将用户切换到步骤1中创建的用户。在

最后，我再怎么强调这一点都不为过。在