]> sipb.mit.edu Git - ikiwiki.git/blob - doc/bugs/autosetup_python_warnings.mdwn
5c081dac28cd85f04aed4bf202d5757c65b5db04
[ikiwiki.git] / doc / bugs / autosetup_python_warnings.mdwn
1 ## What I did
2
3 A friend reported this, and I'm seeing it too. With 3.20140916, on
4 a system with Python 2.7 and 3.4 (and little else) installed, I
5 tried to run the auto.setup:
6
7     :; ikiwiki --setup /etc/pkg/ikiwiki/auto.setup
8     What will the wiki be named? Import Errors
9     What revision control system to use? git
10     Which user (wiki account or openid) will be admin? schmonz
11     
12     
13     Setting up Import Errors ...
14     Importing /Users/schmonz/ImportErrors into git
15     Initialized empty shared Git repository in /Users/schmonz/ImportErrors.git/
16     Initialized empty Git repository in /Users/schmonz/ImportErrors/.git/
17     [master (root-commit) 20b1128] initial commit
18      1 file changed, 1 insertion(+)
19      create mode 100644 .gitignore
20     Counting objects: 3, done.
21     Writing objects: 100% (3/3), 230 bytes | 0 bytes/s, done.
22     Total 3 (delta 0), reused 0 (delta 0)
23     To /Users/schmonz/ImportErrors.git
24      * [new branch]      master -> master
25     Directory /Users/schmonz/ImportErrors is now a clone of git repository /Users/schmonz/ImportErrors.git
26     Traceback (most recent call last):
27       File "/usr/pkg/lib/ikiwiki/plugins/rst", line 45, in <module>
28         from proxy import IkiWikiProcedureProxy
29       File "/usr/pkg/lib/ikiwiki/plugins/proxy.py", line 41, in <module>
30         import xml.parsers.expat
31       File "/usr/pkg/lib/python3.4/xml/parsers/expat.py", line 4, in <module>
32         from pyexpat import *
33     ImportError: No module named 'pyexpat'
34     
35     
36     Creating wiki admin schmonz ...
37     Choose a password:
38     [...]
39
40 ## What I expected
41
42 I expected to get a basic site.
43
44 ## What happened instead
45
46 I got a basic site with some Python error messages.
47
48 ## Likely fix
49
50 Looks like `proxy.py` needs the trick from [[!debbug 637604]] so
51 that it can defer a few imports (at least `xml.parsers.expat` and
52 the XML-RPC libs) until the methods using them are called. --[[schmonz]]
53
54 -----
55
56 It's more complicated than I thought. Findings and questions:
57
58 ### Failing to load an external plugin should be an error
59
60 When a typical Perl plugin fails to load (say, by failing to compile),
61 `IkiWiki::loadplugin()` throws an exception. For XML-RPC plugins
62 written in any language, ikiwiki assumes loading succeeded.
63
64 Let's take [[!iki plugins/rst]] as an example. It's written in
65 Python and uses `proxy.py` to handle XML-RPC communication with
66 ikiwiki. Let's say that `proxy.py` compiles, but `rst` itself
67 doesn't. We'd like ikiwiki to know the module isn't loaded, and
68 we'd like an error message about it (not just the Python errors).
69
70 Now let's say `rst` would be fine by itself, but `proxy.py` doesn't
71 compile because some of the Python modules it needs are missing
72 from the system. (This can't currently happen on Debian, where
73 `libpython2.7` includes `pyexpat.so`, but pkgsrc's `python27`
74 doesn't; it's in a separate `py-expat` package.) As before, we'd
75 like ikiwiki to know `rst` didn't load, but that's trickier when
76 the problem lies with the communication mechanism itself.
77
78 For the tricky case, what to do? Some ideas:
79
80 - Figure out where in `auto.setup` we're enabling `rst` by default,
81   and stop doing that
82 - In pkgsrc's `ikiwiki` package, add a dependency on Python and
83   `py-expat` just in case someone wants to enable `rst` or other
84   Python plugins
85
86 For the simple case, I've tried the following:
87
88 [[!template id=gitbranch branch=schmonz/external-plugin-loading author="[[schmonz]]"]]
89
90 - In `IkiWiki::Plugin::external::import()`, capture stderr
91 - Before falling off the end of `IkiWiki::Plugin::external::rpc_call()`,
92   if the command had been 'import' and stderr is non-empty, throw
93   an exception
94 - In `IkiWiki::loadplugin()`, try/catch/throw just like we do with
95   regular non-external plugins
96
97 With these changes, we have a test that fails when an external
98 plugin can't be loaded (and passes, less trivially, when it can).
99 Huzzah! (I haven't tested yet whether I've otherwise completely
100 broken the interface for external plugins. Not-huzzah!) --[[schmonz]]