I am fine with the idea of passing a standard [YAML] container-resources configuration file to applications, but I mostly care about the orthogonal underlying 'copy a virtualenv to another server' use case. My proposal:<br><br>site.py should honor a new environment variable PYTHONAPPBASE, similar to PYTHONUSERBASE or PYTHONHOME.<br><br>PYTHONAPPBASE causes site.py to add an additional site-packages directory in PYTHONAPPBASE/lib/python2.7/site-packages or Lib/site-packages etc. in the same way the current site-packages paths are chosen.<br><br>(Optional) If that's not good enough, PYTHONAPPSITE specifies a directory that is given to site.addsitepackages(). A maximum of 1 directory within PYTHONAPPBASE can be added.<br><br>site.py gains APP_BASE and APP_SITE in the same way it currently contains USER_BASE and USER_SITE.<br><br>All other paths such as PYTHONAPPBASE/src/mypackage-0.1/src/__init__.py are resolved with .pth files that must contain relative paths only.<br><br>Definitions:<br><br>runtime: Python libraries available to but outside the webapp. Chosen by setting PYTHONHOME. The application metadata might choose a runtime by name, and the application server might display the results of 'pip freeze' for the runtime to help you build a matching development environment.<br><br>app.wsgi is the initial entry point /for the WSGI application/ but scripts can be run by setting up the environment in the same way.<br><br>To configure such an application with uWSGI then, if the Python runtime is in /runtimeA and the web application package is in /application, you would provide the following uWSGI configuration:<br><br>[uwsgi]<br>pyhome=/runtimeA<br>chdir=/application<br>file=/application/app.wsgi<br>env=PYTHONAPPBASE=/application<br># to be specified later:<br>env=STANDARD_CONFIGURATION_FILE=/some-container-services.yaml<br><br>When app.wsgi starts it can access any libraries from /runtimeA/lib/python2.7/site-packages and any libraries from /application/lib/python2.7/site-packages<br><br>Since PYTHONPATH comes from site.py, not app.wsgi, it's very easy to perform the same setup for any other scripts within /application/<br><br><br>Is this anything?<br><br>Daniel Holth<br>