Open prymitive opened 10 years ago
uwsgip_NAME.so
or something. That'd help with enumerating them (as well as possibly with making tracebacks more intelligible).For core we could benefit from cmd line option that would print informations about build config, mostly what features were enabled during build (ssl, pcre, json, debug), like with nginx:
uwsgi --cflags
already exists. (Roberto is one step ahead of us there. :D)
poyo:~$ uwsgi --cflags
-O2 -I. -Wall -Werror -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -fno-strict-aliasing -Wextra -Wno-unused-parameter -Wno-missing-field-initializers -DUWSGI_HAS_IFADDRS -DUWSGI_LOCK_USE_MUTEX -DUWSGI_EVENT_USE_EPOLL -DUWSGI_EVENT_TIMER_USE_TIMERFD -DUWSGI_EVENT_FILEMONITOR_USE_INOTIFY -DUWSGI_EMBEDDED -DUWSGI_UDP -DUWSGI_VERSION="\"1.4.4\"" -DUWSGI_VERSION_BASE="1" -DUWSGI_VERSION_MAJOR="4" -DUWSGI_VERSION_MINOR="4" -DUWSGI_VERSION_REVISION="0" -DUWSGI_VERSION_CUSTOM="\"\"" -DUWSGI_ASYNC -DUWSGI_MULTICAST -DUWSGI_MINTERPRETERS -DUWSGI_INI -DUWSGI_YAML -DUWSGI_SSL -DUWSGI_SNMP -DUWSGI_THREADING -DUWSGI_PLUGIN_DIR=\".\" -DUWSGI_SPOOLER -DUWSGI_DECLARE_EMBEDDED_PLUGINS="UDEP(python);UDEP(gevent);UDEP(ping);UDEP(cache);UDEP(nagios);UDEP(rrdtool);UDEP(carbon);UDEP(rpc);UDEP(corerouter);UDEP(fastrouter);UDEP(http);UDEP(ugreen);UDEP(signal);UDEP(syslog);UDEP(rsyslog);UDEP(logsocket);UDEP(router_uwsgi);UDEP(router_redirect);UDEP(router_basicauth);UDEP(zergpool);UDEP(redislog);UDEP(mongodblog);UDEP(router_rewrite);UDEP(router_http);UDEP(logfile);UDEP(router_cache);UDEP(rawrouter);" -DUWSGI_LOAD_EMBEDDED_PLUGINS="ULEP(python);ULEP(gevent);ULEP(ping);ULEP(cache);ULEP(nagios);ULEP(rrdtool);ULEP(carbon);ULEP(rpc);ULEP(corerouter);ULEP(fastrouter);ULEP(http);ULEP(ugreen);ULEP(signal);ULEP(syslog);ULEP(rsyslog);ULEP(logsocket);ULEP(router_uwsgi);ULEP(router_redirect);ULEP(router_basicauth);ULEP(zergpool);ULEP(redislog);ULEP(mongodblog);ULEP(router_rewrite);ULEP(router_http);ULEP(logfile);ULEP(router_cache);ULEP(rawrouter);"
pip.vcs
wouldn't be a terrible idea: https://github.com/pypa/pip/blob/develop/pip/vcs/__init__.pyAFAIK name is already standardized, uWSGI build system produces NAME_plugin.so files
About --cflags
- I was thinking about something more human readable, like the output of uWSGI build commands:
$ make
[...]
################# uWSGI configuration #################
pcre = True
kernel = Linux
malloc = libc
execinfo = False
ifaddrs = True
ssl = False
zlib = False
locking = pthread_mutex
plugin_dir = .
timer = timerfd
yaml = embedded
json = False
filemonitor = inotify
routing = True
debug = False
capabilities = False
xml = expat
event = epoll
############## end of uWSGI configuration #############
pip.vcs might be handy, if we can import it and user puts vcs link in the list of plugins to build we can use it to fetch and build such plugin and fail with clear message that pip.vcs and/or git/bzr/svn binaries are missing. But IMHO we should not make it hard requirements for building uWSGI,
No, not a hard requirement, but for VCS links.
ok for adding more hooks in the plugin structure (in 2.1)
.api = 1 (defines the minum uWSGI version required, this is independent from uWSGI version, api 1 will map to uWSGI 2.1, as api 2 could map to uWSGI 4.0) Generally when structures of uwsgi.h changes we need to define a new api version.
With this hook we can even check if a plugin uses different structures and will crash soon or later
.version = "" (a string related to the plugin version)
.author = "" (a string related to the plugin author)
.url = "" (the homepage of the plugin)
.description = "" (the plugin description)
All of them must be optional
With new policy that all new plugins should be developed as separate pieces, outside of core uWSGI, we should think about adding more data to plugin struct and maybe enhance build process a little bit.
First of all all plugins should be versioned so that user will know if he is running up to date version. So plugin struct should also have:
With such information compiled into plugins we could print them during uWSGI start. So it's clear if user is using latest code, or some old version of given plugin. Maybe we could add
--print-plugins
option that would just list all available plugins with version information. For plugins as .so it would be harder but if user would set plugins path maybe we could scan that dir(s) and try to load all found plugins (?)For core we could benefit from cmd line option that would print informations about build config, mostly what features were enabled during build (ssl, pcre, json, debug), like with nginx:
Last thing is build script, I was thinking about adding support for compiling external plugins right out of uwsgiconfig.py if user would put repo link instead of name. For example:
uwsgiconfig.py would clone repo from github and compile that plugin as any other included in uWSGI sources. This should be easy to implement but would make building uWSGI with bunch of external plugins easy (I can work on this during weekend).
Any thoughts?