I decided that I was going to add embedded python to exim in the same
manner than perl is embedded. I did some plumbing for exim to be
configured for it, then build and link it. I just finished that
portion and pushed up to my personal branch. I have been working on
this since last week (started on it after I pushed the opendmarc
branch.)
Over the past couple of days, while ironing out the kinks in the build
process, I was hitting an issue getting the python code to import. I
went and asked in the #python irc channel. HOLY CRAP was that the
wrong thing to do. I was told I was stupid for trying to embed python
into an existing app because I lose so much of the power of python. I
was also told it would probably be just as stupid to embed perl into
my app. I admit I kind of laughed at that. They referred me to
http://twistedmatrix.com/users/glyph/rant/extendit.html which kindly
explains that I should reconfigure my app to be a module of python,
not to embed python in the app.
I think I'm just going to chalk it up to a rabid fanbase (not bad,
it's a good thing!) who thinks that the ONE TRUE WAY is to use python
for everything and just won't consider that it could be useful in
another way.
My question to the devs is simple: is it even worth my time to give
embedded python capability to exim?
Python has a very simple initialization procedure, that part works
with no issues. The show-stopper problem I have so far is that I'm
giving it a script to import that is in exim's config directory
instead of in the python search path. From the shell, I can specify
an additional subdirectory to look in when importing modules, but I
couldn't find a simple function in the python api to make it add a
path to the python module loader search paths.
Suggestions, comments, and insight are appreciated.
...Todd
--
The total budget at all receivers for solving senders' problems is $0.
If you want them to accept your mail and manage it the way you want,
send it the way the spec says to. --John Levine
