search

unbit / uwsgi

uWSGI application server container
http://projects.unbit.it/uwsgi
Other
3.46k stars 691 forks source link

Enhancing build system for external plugins #505

Open prymitive opened 10 years ago

prymitive commented 10 years ago

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:

# nginx -V
nginx version: nginx/1.2.9
TLS SNI support enabled
configure arguments: --prefix=/usr/share/nginx --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-client-body-temp-path=/var/lib/nginx/body --http-fastcgi-temp-path=/var/lib/nginx/fastcgi --http-log-path=/var/log/nginx/access.log --http-proxy-temp-path=/var/lib/nginx/proxy --http-scgi-temp-path=/var/lib/nginx/scgi --http-uwsgi-temp-path=/var/lib/nginx/uwsgi --lock-path=/var/lock/nginx.lock --pid-path=/var/run/nginx.pid --with-pcre-jit --with-debug --with-http_addition_module --with-http_dav_module --with-http_geoip_module --with-http_gzip_static_module --with-http_image_filter_module --with-http_realip_module --with-http_stub_status_module --with-http_ssl_module --with-http_sub_module --with-http_xslt_module --with-ipv6 --with-sha1=/usr/include/openssl --with-md5=/usr/include/openssl --with-mail --with-mail_ssl_module --add-module=/build/buildd/nginx-1.2.9/debian/modules/nginx-auth-pam --add-module=/build/buildd/nginx-1.2.9/debian/modules/nginx-dav-ext-module --add-module=/build/buildd/nginx-1.2.9/debian/modules/nginx-echo --add-module=/build/buildd/nginx-1.2.9/debian/modules/nginx-upstream-fair --add-module=/usr/lib/phusion-passenger/ext/nginx --add-module=/build/buildd/nginx-1.2.9/debian/modules/nginx-upstream-check-module

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:

[uwsgi]
main_plugin = git+https://github.com/unbit/plugin.git
inherit = base

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?

akx commented 10 years ago
prymitive commented 10 years ago

AFAIK 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,

akx commented 10 years ago

No, not a hard requirement, but for VCS links.

unbit commented 10 years ago

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