idlesign/uwsgiconf

Configure uWSGI from your Python code

uwsgiconf

https://github.com/idlesign/uwsgiconf

Description

Configure uWSGI from your Python code

If you think you know uWSGI you're probably wrong. It is always more than you think it is. There are so many subsystems and options (800+) it is difficult to even try to wrap your mind around.

uwsgiconf allowing to define uWSGI configurations in Python tries to improve things the following ways:

• It structures options for various subsystems using classes and methods;
• It uses docstrings and sane naming to facilitate navigation;
• It ships some useful presets to reduce boilerplate code;
• It encourages configuration reuse;
• It comes with CLI to facilitate configuration;
• It features easy to use and documented uwsgi stub Python module;
• It offers runtime package, similar to uwsgidecorators, but with more abstractions;
• It features integration with Django Framework;
• It is able to generate configuration files for Systemd, Upstart.
• It can use pyuwsgi.

Consider using IDE with autocompletion and docstings support to be more productive with uwsgiconf.

By that time you already know that uwsgiconf is just another configuration method. Why?

Overview

Static configuration

Let's make uwsgicfg.py. There we configure uWSGI using nice PythonSection preset to run our web app.

from uwsgiconf.config import configure_uwsgi
from uwsgiconf.presets.nice import PythonSection


def get_configurations():
    """This should return one or more Section or Configuration objects.
    In such a way you can configure more than one uWSGI instance in the same place.

    Here we'll define just one configuration section, which
    will instruct uWSGI to serve WSGI application (from wsgi.py module)
    on http://127.0.0.1:8000. We use .bootstrap shortcut method
    to construct our configuration section object.

    """
    return PythonSection.bootstrap('http://127.0.0.1:8000', wsgi_module='/home/idle/myapp/wsgi.py')


# Almost done. One more thing:
configure_uwsgi(get_configurations)

1. Now if you want to generate myconf.ini file and use it for uWSGI manually you can do it with:

   $ uwsgiconf compile > myconf.ini
   $ uwsgi myconf.ini

2. Or use uwsgiconf to automatically spawn uWSGI processes for configurations defined in your module:

   $ uwsgiconf run

Note: uwsgiconf CLI requires click package available (can be installed with uwsgiconf).

Runtime configuration

uwsgiconf comes with runtime package which is similar to uwsgidecorators but offers different abstractions to provide useful shortcuts and defaults.

These abstractions will also use a stub uwsgi module when the real one is not available.

A couple of examples:

from uwsgiconf.runtime.locking import lock
from uwsgiconf.runtime.scheduling import register_timer_rb

@register_timer_rb(10, repeat=2)
def repeat_twice():
    """This function will be called twice with 10 seconds interval
    using red-black tree based timer.

    """
    with lock():
        # Code under this context manager will be locked.
        do_something()

Allows for runtime access to:

• Alarms
• Caches
• Locks
• Logging
• Monitoring
• Mules
• RPC
• Scheduling
• Signals
• Websockets
• and more

Third parties support

Django

Run your Django-based project on uWSGI using manage command:

$ ./manage.py uwsgi_run
$ ./manage.py uwsgi_reload --force

• Other commands are available.
• uWSGI summary and statistics are also available from Admin interface.

System configs

Compile system service config (e.g systemd) to run your uWSGI-powered project:

$ uwsgiconf sysinit systemd

Documentation

More information can be found at http://uwsgiconf.readthedocs.org/

uwsgiconf's Issues

Improve register_cron

For introspection:

• Add is_cron attribute to a function
• Maybe save schedule args.
• Maybe make signal arg passing optional.
• Maybe make a cron registry for introspection.

RTD. Autodoc doesn't work

E.g. https://uwsgiconf.readthedocs.io/en/latest/run_alarms.html
need to fix autodoc missing from documentation.
Need to somehow instruct autodoc to use docstrings for aliases from actual functions.

Unify type annotations in `uwsgiconf.uwsgi_stub` with `types-uWSGI`

Hi there,
types-uWSGI has been accepted and merged into typeshed today (it should be available on pypi by tomorrow)

First of all, let me thank you for your work. It's been great having someone else's stubs to double check my own stubs against. It's quicker than double checking the C-Code, where it's easy to miss an argument here or there or misread whether or not it's a default argument. It helped me find a handful of errors I've made when creating the stubs, but I've also discovered quite a few errors in your stubs along the way.

So I'd recommend checking your stubs against types-uWSGI. One of the big things that you got wrong, is that you annotated all the arguments as named, when they're actually positional only arguments, if you don't care about supporting 3.7 or lower, then you can put a / at the end of each argument list, or if you do, then you can use the workaround I used in the stubs of prefixing the argument names with a double underscore.

The other big thing is, that you weren't using the 2.0.21 release tag as a reference, but master, which contains some new functions/arguments that are not part of 2.0.21, I've made the same mistake initially, but figured it out when I was trying to add annotations for the request_context argument on the websocket functions.

One relatively quick way to compare the stubs, rather than to do it manually, would probably be to copy uwsgi.pyi from types-uWSGI into uwsgi_stub.pyi and use stubtest which lets you test a pyi file against the runtime types in a module.

mule_farm handling for strings

.workers.set_mules_params(farms=[PythonSection.workers.mule_farm(16)]) produces wrong config if 16 is given as a string.
Need also to consider a possibility to accept and handle numeric strings.