So far I've (quite successfully ;-) avoided the issue
of where/how/what/when per-interpreter initialization
should come from.

Currently, the initialization is compiled in with the
interpreter wrappers, which was quick and easy devel.

E.g., here's what %{python:...} loads when instantiated:

#if defined(WITH_PYTHONEMBED)
static const char * rpmpythonInitStringIO = "\
import sys\n\
from cStringIO import StringIO\n\
sys.stdout = StringIO()\n\
import rpm\n\
";
#endif

That goop needs to be slurped from an
external configure file somehow.

Which means that RPM needs to commit to
some convention for per-interpreter initialization.

What has been wired up with Lua was perfectly OK when
just LUA was embedded. But those conventions, and
--rpmlua, just aren't gonna scale to 5 interpreters.

What I'd like to see is a per-interpreter config macro
carrying the usual colon separated paths that are slurped
and loaded when an embedded interpreter is instantiated.

What I'd like to fix, is the hardwired compiled in paths
for LUA, and remove --rpmlua as a compiled in option.
A popt alias should suffice for all the emebedded interpreters,
the only "feature" reversion is attempting to run
the rpm executable without _ANY_ configuration. These
days, while you can still override everything in
RPM from the CLI, its highly unlikely you will achieve
much joy, as way too much rpm configuration is already
being loaded from all over the place. JMHO, YMMV.

I'll wire up some KISS convention like
	/usr/lib/rpm/embed/{ruby,...}.init
in a flash if there's consensus.

(new topic)
I haven't a clue where to install js/libjsm.so, JavaScript
has no clear conventional guidance for paths to search for
extension modules. Shall I just dump libjsm.so into
/usr/lib/rpm, or should I attempt /usr/lib/rpm/js/*
instead?

73 de Jeff