uwsgi.ini configuration for python apps
I found the answer myself after digging through the uwsgi docs a little.
Reference, https://uwsgi-docs.readthedocs.io/en/latest/ConfigLogic.html, we can specify configuration logic and dynamically compute paths by making use of environment variables while in a python virtualenv.
So assuming that I am currently in my myproject virtualenv, my .ini configuration will automatically compute my paths for chdir and virtualenv .ini configuration options like this:
[uwsgi]
if-env = PROJECT_HOME
print = Your path is %(_)/myproject
chdir = %(_)/myproject
endif =
if-env = VIRTUAL_ENV
print = Your virtualenv is %(_)
virtualenv = %(_)
endif =
socket=127.0.0.1:3034
module=django.core.handlers.wsgi:WSGIHandler()
env= DJANGO_SETTINGS_MODULE=bbox.settings
master=True
pidfile=/tmp/project-master.pid
vacuum=True
max-requests=5000
daemonize=/var/log/uwsgi/yourproject.log
The print statement is optional of course, but this gives the uwsgi binary the values for chdir and virtualenv that it is expecting.
Something like this:
calvin$ uwsgi --ini myproject/uwsgi.ini
[uWSGI] getting INI configuration from myproject/uwsgi.ini
Your path is /Users/calvin/work/myproject
Your virtualenv is /Users/calvin/.virtualenvs/myproject
*** Starting uWSGI 1.2.4 (64bit) on [Thu Jul 26 17:00:04 2012] ***
compiled with version: 4.2.1 Compatible Apple Clang 3.1 (tags/Apple/clang-318.0.61) on 25 July 2012 20:06:56
detected number of CPU cores: 8
The print statements are unnecessary in your final .ini file of course. I am just placing them there so as to print out the necessary info which confirms that my paths are dynamically computed in the .ini file.
I'm not sure it's a good practice to run development and production versions with different config files - this is typically a way to "strange" issues which does not appear in dev version (due to different file permissions or whatever). Much better is to do smth like make install and always work with production-like configuration. Or, you may just link your sources to project directory in your homedir to edit them in-place. But again, your configuration is unique.
Building up on the answer given by Calvin, with the use of the '@' magic one can have more flexibility regarding dynamic configurations.
The @(exec://...) can be useful for example to evaluate bash commands. In my case it allowed me to define:
realpath = @(exec://bash -c 'dirname `readlink -f %p`')
Which I was looking for since I had symlinked this configuration from another directory.