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 Debian bug #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 so far:
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 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 plugin 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 enablingrst
by default, and stop doing that - In pkgsrc's
ikiwiki
package, add a dependency on Python andpy-expat
just in case someone wants to enablerst
or other Python plugins
For the simple case, I've tried the following:
- 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