[gentoo-dev] New USE_EXPANDs for uWSGI: UWSGI_LANGUAGES, UWSGI_PLUGINS and plans for uwsgi-2

[gentoo-dev] New USE_EXPANDs for uWSGI: UWSGI_LANGUAGES, UWSGI_PLUGINS and plans for uwsgi-2

[Tiziano Müller]

Hi everyone,

the new versions of uwsgi (1.9+) support even more languages/platforms
and plugins.

Currently we do everything with common USE flags and build-in many
plugins since we didn't want to expose them right from the start to the
user (the selection is based on upstreams base configuration).

For the new version, uWSGI will support the following
languages/platforms which we would like to put in UWSGI_LANGUAGES:
python (vanilla, gevent, ugreen, stackless), ruby (rack, RoR & fibers),
perl, lua, erlang (+pyerl), php, go, java (jvm & clojure), mono,
javascript (via v8).
For some of them it is even possible to enable/disable the specific
interface (for example ruby fibers or java clojure) but if they don't
pull in additional dependencies we continue with the current approach
and build all interfaces for a language.

For the UWSGI_PLUGINS we would add the following flags:
ping, cache, nagios, rrdtool, carbon, rpc, corerouter, fastrouter, http,
ugreen, signal, syslog, rsyslog, logsocket, router_uwsgi,
router_redirect, router_basicauth, zergpool, redislog, mongodblog,
router_rewrite, router_http, logfile, router_cache, rawrouter,
router_static, sslrouter, spooler, cheaper_busyness, symcall,
transformation_tofile, transformation_gzip, gridfs,
stats_pusher_mongodb, stats_pusher_statsd, spooler, xslt
(plus some more)

While the following will remain normal USE flags:
xml, yaml, json, zeromq, ssl, pcre
since they are not plugins but general capabilities of uWSGI.

The drawback of putting for example "python" behind a UWSGI_LANGUAGES
USE_EXPAND is that someone with USE=python in make.conf does not get
python-support in uWSGI automatically but has to enable it explicitly.
On the other hand, uWSGI gets installed explicitly and people most
likely check things before installing them.

Furthermore we may want to switch to an all-plugin-based installation as
available for Debian, openSUSE, etc. as recommended by upstream [1]
(currently we're only building the language plugins as real plugins). It
doesn't really matter as much as it does for binary package distros but
it also doesn't hurt (please correct me if wrong) and this way our users
can share their configs between distros.

Ok to add those two USE_EXPANDs?

Any comments on the other plans?

Best,
Tiziano

[1] http://projects.unbit.it/uwsgi/wiki/Guide4Packagers