diff options
author | Amitai Schlair <schmonz-web-ikiwiki@schmonz.com> | 2014-10-13 16:13:11 -0400 |
---|---|---|
committer | Amitai Schlair <schmonz-web-ikiwiki@schmonz.com> | 2014-10-13 16:13:33 -0400 |
commit | e42b1409b242e75df9318d6472fe6adf7ba00df2 (patch) | |
tree | b1f2670c7c07644c92e985556cc11c101d66a3f1 /doc | |
parent | 17fccbca94aafc112fd72929ba4e7205ceedc287 (diff) | |
download | ikiwiki-e42b1409b242e75df9318d6472fe6adf7ba00df2.tar ikiwiki-e42b1409b242e75df9318d6472fe6adf7ba00df2.tar.gz |
findings and questions
Diffstat (limited to 'doc')
-rw-r--r-- | doc/bugs/autosetup_python_warnings.mdwn | 48 |
1 files changed, 48 insertions, 0 deletions
diff --git a/doc/bugs/autosetup_python_warnings.mdwn b/doc/bugs/autosetup_python_warnings.mdwn index f17c8658e..5c081dac2 100644 --- a/doc/bugs/autosetup_python_warnings.mdwn +++ b/doc/bugs/autosetup_python_warnings.mdwn @@ -50,3 +50,51 @@ I got a basic site with some Python error messages. Looks like `proxy.py` needs the trick from [[!debbug 637604]] so that it can defer a few imports (at least `xml.parsers.expat` and the XML-RPC libs) until the methods using them are called. --[[schmonz]] + +----- + +It's more complicated than I thought. Findings and questions: + +### Failing to load an external plugin should be an error + +When a typical Perl plugin fails to load (say, by failing to compile), +`IkiWiki::loadplugin()` throws an exception. For XML-RPC plugins +written in any language, ikiwiki assumes loading succeeded. + +Let's take [[!iki plugins/rst]] as an example. It's written in +Python and uses `proxy.py` to handle XML-RPC communication with +ikiwiki. Let's say that `proxy.py` compiles, but `rst` itself +doesn't. We'd like ikiwiki to know the module isn't loaded, and +we'd like an error message about it (not just the Python errors). + +Now let's say `rst` would be fine by itself, but `proxy.py` doesn't +compile because some of the Python modules it needs are missing +from the system. (This can't currently happen on Debian, where +`libpython2.7` includes `pyexpat.so`, but pkgsrc's `python27` +doesn't; it's in a separate `py-expat` package.) As before, we'd +like ikiwiki to know `rst` didn't load, but that's trickier when +the problem lies with the communication mechanism itself. + +For the tricky case, what to do? Some ideas: + +- Figure out where in `auto.setup` we're enabling `rst` by default, + and stop doing that +- In pkgsrc's `ikiwiki` package, add a dependency on Python and + `py-expat` just in case someone wants to enable `rst` or other + Python plugins + +For the simple case, I've tried the following: + +[[!template id=gitbranch branch=schmonz/external-plugin-loading author="[[schmonz]]"]] + +- In `IkiWiki::Plugin::external::import()`, capture stderr +- Before falling off the end of `IkiWiki::Plugin::external::rpc_call()`, + if the command had been 'import' and stderr is non-empty, throw + an exception +- In `IkiWiki::loadplugin()`, try/catch/throw just like we do with + regular non-external plugins + +With these changes, we have a test that fails when an external +plugin can't be loaded (and passes, less trivially, when it can). +Huzzah! (I haven't tested yet whether I've otherwise completely +broken the interface for external plugins. Not-huzzah!) --[[schmonz]] |