python - 根据 Linux 文件系统层次结构标准，放置 Python 虚拟环境的正确位置在哪里？

Question

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

用另一种方式来明确回答:将 Python 虚拟环境的位置与您提供的数据文件分开“在技术上是正确的”吗？

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

更复杂的是，我倾向于编写支持互联网访问服务的代码。但是，我认为这并没有将我的需求与服务的消费者是同一服务器上的其他进程的场景区分开来。我提到这个细节是为了防止我对评论的回复包含“网络开发”式的内容。

作为引用，我使用以下文档作为我对 Linux FHS 的定义:http://www.pathname.com/fhs/pub/fhs-2.3.html

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

从文件系统的根级别，我倾向于/usr (可共享的只读数据)或 /srv (本系统提供的服务的数据)，但这是我很难进一步决定的地方。

如果我要与我的首选反向代理一起做出决定，那意味着 /usr . Nginx 通常打包到/usr/share/nginx 或/usr/local/nginx，但是/usr/应该是 mounted read-only according to the FHS .我觉得这很奇怪，因为我从来没有参与过一个项目，在这个项目中，开发进展得如此缓慢，以至于“以只读方式卸载/重新挂载写入，以只读方式卸载/重新挂载”被认为是值得的。

/srv是另一个可能的位置，但被表述为“特定服务的数据文件的位置”，而 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 应用程序的反向代理的常见场景。在 /usr/local/service_name/ 下放置虚拟环境和源代码(例如 application.py)是否正确，而使用 /srv 用于更频繁更改的文件(例如“静态” Assets 、图像、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 称为标准 - 这只是一堆使支持 Linux 更容易的规则。

/run、/sys、/proc 和 /usr/local 都不属于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 的列表, 并将 this 放入版本控制中。请记住，虚拟环境并非完全可移植。
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)?

静态 Assets 不是动态文件，我认为您混淆了术语。

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

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

最后，我如何强调记录您的过程和自动化。