## What I did

A friend reported this, and I'm seeing it too. With 3.20140916, on
a system with Python 2.7 and 3.4 (and little else) installed, I
tried to run the auto.setup:

    :; ikiwiki --setup /etc/pkg/ikiwiki/auto.setup
    What will the wiki be named? Import Errors
    What revision control system to use? git
    Which user (wiki account or openid) will be admin? schmonz
    
    
    Setting up Import Errors ...
    Importing /Users/schmonz/ImportErrors into git
    Initialized empty shared Git repository in /Users/schmonz/ImportErrors.git/
    Initialized empty Git repository in /Users/schmonz/ImportErrors/.git/
    [master (root-commit) 20b1128] initial commit
     1 file changed, 1 insertion(+)
     create mode 100644 .gitignore
    Counting objects: 3, done.
    Writing objects: 100% (3/3), 230 bytes | 0 bytes/s, done.
    Total 3 (delta 0), reused 0 (delta 0)
    To /Users/schmonz/ImportErrors.git
     * [new branch]      master -> master
    Directory /Users/schmonz/ImportErrors is now a clone of git repository /Users/schmonz/ImportErrors.git
    Traceback (most recent call last):
      File "/usr/pkg/lib/ikiwiki/plugins/rst", line 45, in <module>
        from proxy import IkiWikiProcedureProxy
      File "/usr/pkg/lib/ikiwiki/plugins/proxy.py", line 41, in <module>
        import xml.parsers.expat
      File "/usr/pkg/lib/python3.4/xml/parsers/expat.py", line 4, in <module>
        from pyexpat import *
    ImportError: No module named 'pyexpat'
    
    
    Creating wiki admin schmonz ...
    Choose a password:
    [...]

## What I expected

I expected to get a basic site.

## What happened instead

I got a basic site with some Python error messages.

## Likely fix

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]]