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发行版中看到它们.
但是,在大多数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?
我不确定您所使用的“数据文件”是什么意思,但以下是虚拟环境的规则:
>不要将它们放在源代码管理中.
>维护installed packages的列表,并将其置于版本控制中.请记住,虚拟环境不是完全可移植的.
>将您的虚拟环境与源代码分开.
鉴于上述情况,您应该将虚拟环境与源代码分开.
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)?
静态资产不是动态文件,我认为你的条款令人困惑.
无论哪种方式,您都应该执行以下操作:
>创建用户帐户以运行该应用程序.
>将应用程序文件放在由该用户和该用户单独控制的目录下.通常这是/ home / username目录,但您可以使用/ services / servicename.将虚拟环境作为此目录的子集,以标准命名格式放置.例如,我使用env.
>将静态资产(例如所有媒体文件,css文件等)放在前端服务器可读的目录中.所以,通常你会创建一个www目录或一个public_html目录.
>确保为此应用程序创建的用户帐户具有对此资产目录的写入权限,以便您能够更新文件.代理服务器不应对此目录具有执行权限.您可以通过将目录组更改为与代理服务器用户的组相同来完成此操作.鉴于此,我将此目录放在/ home / username /或/ services / servicename下.
>使用流程管理器启动应用程序,并确保流程管理器在运行应用程序代码时将用户切换到步骤1中创建的用户.
最后,我不能强调这足以记录您的过程和自动化.