所以我正在试验 uWSGI 并且非常喜欢它。
不过,我对使用其 .ini 文件有疑问。
是否可以动态计算其 .ini 配置参数的值?
例如,对于我的“uwsgi.ini”文件中的“chdir”值,我有
[uwsgi]
socket=127.0.0.1:3034
chdir=/Users/calvin/work/myproject
virtualenv=/Users/calvin/.virtualenvs/myproject
module=django.core.handlers.wsgi:WSGIHandler()
env= DJANGO_SETTINGS_MODULE=myproject.settings
master=True
pidfile=/tmp/myproject-master.pid
vacuum=True
max-requests=5000
daemonize=/var/log/uwsgi/myproject.log
必须为我的“本地机器”、我的“开发/暂存”服务器和我的“生产服务器”编写 3 个单独的 .ini 文件是一件很麻烦的事情。更何况同事的本地机器的chdir
价值会完全不同。
我尝试使用import os
和动态os.join.path
计算chdir
值,但它不起作用,这是预料之中的,因为 uwsgi 没有 python 解释器?
在仔细研究了 uwsgi 文档后,我自己找到了答案。
参考,https://uwsgi-docs.readthedocs.io/en/latest/ConfigLogic.html,我们可以在 python virtualenv 中通过使用环境变量来指定配置逻辑和动态计算路径。
所以假设我目前在我的
myproject
virtualenv 中,我的 .ini 配置将自动计算我的路径chdir
和virtualenv
.ini 配置选项,如下所示:print 语句当然是可选的,但这为 uwsgi 二进制文件提供了它所期望的
chdir
值virtualenv
。是这样的:
当然,最终的 .ini 文件中不需要打印语句。我只是将它们放在那里,以便打印出必要的信息,确认我的路径是在 .ini 文件中动态计算的。
我不确定使用不同的配置文件运行开发和生产版本是一个好习惯——这通常是一种解决“奇怪”问题的方法,这些问题不会出现在开发版本中(由于不同的文件权限或其他原因)。更好的做法是像做 smth 一样
make install
并始终使用类似生产的配置。或者,您可以将源代码链接到主目录中的项目目录,以就地编辑它们。但同样,您的配置是独一无二的。在 Calvin 给出的答案的基础上,使用“@”魔法可以在动态配置方面具有更大的灵活性。
例如,这
@(exec://...)
对于评估 bash 命令很有用。在我的例子中,它允许我定义:realpath = @(exec://bash -c 'dirname `readlink -f %p`')
我一直在寻找的东西,因为我已经从另一个目录符号链接了这个配置。