Having multiple version of a Python package/module/file is very common.
Manipulating PYTHONPATH or using virtualenvs are a way to use various versions without changing your code.
But hey, why not have an aliasing system that lets you arbitrarily map module names to files? That’s why we have the pymodule-alias option!
Let’s say we have swissknife.py that contains lots of useful classes and functions.
It’s imported in gazillions of places in your app. Now, we’ll want to modify it, but keep the original file intact for whichever reason, and call it swissknife_mk2.
Your options would be
So don’t touch your files – just remap!
./uwsgi -s :3031 -w myproject --pymodule-alias swissknife=swissknife_mk2
# Kapow! uWSGI one-two ninja punch right there!
# You can put the module wherever you like, too:
./uwsgi -s :3031 -w myproject --pymodule-alias swissknife=/mnt/floppy/KNIFEFAC/SWISSK~1.PY
# Or hey, why not use HTTP?
./uwsgi -s :3031 -w myproject --pymodule-alias swissknife=http://uwsgi.it/modules/swissknife_extreme.py
You can specify multiple pymodule-alias directives.
uwsgi:
socket: :3031
module: myproject
pymodule-alias: funnymodule=/opt/foo/experimentalfunnymodule.py
pymodule-alias: uglymodule=/opt/foo/experimentaluglymodule.py
You have this shiny, beautiful Django project and something occurs to you: Would it work with Django trunk? On to set up a new virtualenv... nah. Let’s just use pymodule-alias!
./uwsgi -s :3031 -w django_uwsgi --pymodule-alias django=django-trunk/django
You have a Werkzeug project where you want to override - for whichever reason - werkzeug.test_app with one of your own devising. Easy, of course!
./uwsgi -s :3031 -w werkzeug.testapp:test_app() --pymodule-alias werkzeug.testapp=mytestapp