Front-end software utilizing cherrypy for resource allocation and management.
For instance, users can run a server in the foreground by importing their web application instance, such as mywebapp.app, and running the command:
`wsgid --application mywebapp.app --foreground`
Another option is running a server in the foreground by importing and calling mywebapp.create_app as the application factory, using the command:
`wsgid --application_factory mywebapp.create_app -f`
There is also a daemonized version using the pidfile mypid.pid after importing and calling mywebapp.create_app as the application factory, guided by the command:
`wsgid --application_factory mywebapp.create_app --pidfile mypid.pid`
To stop a daemonized server using the pidfile mypid.pid, run the command:
`wsgid --pidfile mypid.pid --stop`
These commands have numerous short versions, and offer overriding of default settings in config files or the environment. Users can use ini-style config files to set different options, and then call them using the “config” section. For example, the myserver.ini could have the settings:
```
[config]
pidfile = mypid.pid
application_factory = mywebapp.create_app
```
Then, using the command `wsgid -c myserver.ini` is equivalent to the above examples, diabling the need to run the command manually. However, the actual section titles in the config file are ignored, and the file is essentially flattened.
Wsgid also permits users to override default options using environment variables with uppercased variable names so as to avoid collisions with other apps for common names. For instance, running `export WSGID_PIDFILE=mypid.pid` is equivalent to passing the –pidfile on the command line.
Additionally, there are other complete options offered in Wsgid, which include help (-h), config_file (-c), pidfile (-p), foreground (-f), stop (-s), application (-a), application factory (-A), debug (-d), port (-P), host (-H), logdir(-L), stdredirect (-R), workdir (-w), umask (-U), and servername (-n).
Version 0.9: N/A