So I am experimenting with uWSGI and liking it a lot.

I have a question regarding the use of its .ini file though.

Is it possible to calculate values for its .ini configuration parameter dynamically?

For instance, for the "chdir" value in my "uwsgi.ini" file, I have

env= DJANGO_SETTINGS_MODULE=myproject.settings

It's quite a bother to have to write 3 separate .ini files for my "local machine", my "development/staging" server and my "production server". Not to mention that a colleague's local machine's chdir value will be completely different.

I tried using import os and os.join.path to compute the chdir value dynamically but it doesn't work, which is to be expected since uwsgi does not have a python interpretor?

3 Answers 3


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:


print = Your path is %(_)/myproject
chdir = %(_)/myproject
endif =

if-env = VIRTUAL_ENV
print = Your virtualenv is %(_)
virtualenv = %(_)
endif = 

env= DJANGO_SETTINGS_MODULE=bbox.settings

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.