根据Linux文件系统层次结构标准放置Python虚拟环境的适当位置在哪里?

8 python linux virtualenv fhs

正如标题所示,根据Linux FHS,在Linux操作系统上存储Python虚拟环境的技术上适当的位置是什么?

说明另一种方法,可以得出一个明确的答案:将Python虚拟环境的位置与您服务的数据文件分开是"技术上正确的"吗?

注意:这个问题与我能找到的最接近的,已经问过的问题不同,因为虚拟环境包含库,二进制文件,头文件和脚本.

作为一个额外的复杂性,我倾向于编写支持互联网可访问服务的代码.但是,我并不认为这可以将我的需求与服务的使用者是同一服务器上的其他进程的情况大不相同.我提到这个细节,以防我对评论的回复包括"web dev" - 内容.

作为参考,我使用以下文档作为我对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 /应根据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
Run Code Online (Sandbox Code Playgroud)

根据我的假设和想法:考虑Nginx作为Python应用程序的反向代理的常见场景./usr/local/service_name/在使用/srv更频繁更改的文件(例如"静态"资产,图像,css)时,放置虚拟环境和源代码(例如application.py)是否正确?

编辑:要明确:我知道为什么以及如何使用virtualenvs.我对项目布局或在开发环境中工作并不感到困惑.

Bur*_*lid 6

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

请记住,Linux FHS并不是真正的标准,而是一套指导方针。它仅被 LSB 称为标准 - 这只是一组使支持 Linux 更容易的规则。

/run, /sys,/proc/usr/local都不是 LFS 的一部分,但您可以在大多数 linux 发行版中看到它们。

对我来说,放置虚拟环境的明确选择是/opt,因为该位置保留用于安装附加软件包

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

所以,我会推荐/usr/local(如果它可以由您的普通用户帐户写入)-但是将它安装在您的主目录中没有任何问题。

用另一种方式表达一个明确的答案:将 Python 虚拟环境的位置与您所服务的数据文件分开是否“技术上正确”?

我不确定“您提供的数据文件”是什么意思,但以下是虚拟环境的规则:

  1. 不要将它们置于源代码管理中。
  2. 保持清单安装的软件包,并把这个版本控制。请记住,虚拟环境并不是完全可移植的。
  3. 将您的虚拟环境与源代码分开。

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

考虑 Nginx 充当 Python 应用程序的反向代理的常见场景。将虚拟环境和源代码(例如 application.py)放在 /usr/local/service_name/ 下,同时将 /srv 用于更多动态文件(例如“静态”资产、图像)是否正确?

静态资产不是动态文件,我认为您混淆了术语。

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

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

最后,我再怎么强调也不为过,记录你的过程自动化它