]> git.vanrenterghem.biz Git - git.ikiwiki.info.git/blob - doc/bugs/autosetup_python_warnings.mdwn
Fix getlibdirs when libdirs is unset
[git.ikiwiki.info.git] / doc / bugs / autosetup_python_warnings.mdwn
1 ## What I did
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:
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     [...]
40 ## What I expected
42 I expected to get a basic site.
44 ## What happened instead
46 I got a basic site with some Python error messages.
48 ## Likely fix
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]]
54 -----
56 It's more complicated than I thought. Findings and questions so
57 far:
59 ### Failing to load an external plugin should be an error
61 When a typical Perl plugin fails to load (say, by failing to compile),
62 `IkiWiki::loadplugin()` throws an exception. For XML-RPC plugins
63 written in any language, ikiwiki assumes loading succeeded.
65 Let's take [[!iki plugins/rst]] as an example. It's written in
66 Python and uses `proxy.py` to handle XML-RPC communication with
67 ikiwiki. Let's say that `proxy.py` compiles, but `rst` itself
68 doesn't. We'd like ikiwiki to know the plugin isn't loaded, and
69 we'd like an error message about it (not just the Python errors).
71 Now let's say `rst` would be fine by itself, but `proxy.py` doesn't
72 compile because some of the Python modules it needs are missing
73 from the system. (This can't currently happen on Debian, where
74 `libpython2.7` includes `pyexpat.so`, but pkgsrc's `python27`
75 doesn't; it's in a separate `py-expat` package.) As before, we'd
76 like ikiwiki to know `rst` didn't load, but that's trickier when
77 the problem lies with the communication mechanism itself.
79 For the tricky case, what to do? Some ideas:
81 - Figure out where in `auto.setup` we're enabling `rst` by default,
82   and stop doing that
83 - In pkgsrc's `ikiwiki` package, add a dependency on Python and
84   `py-expat` just in case someone wants to enable `rst` or other
85   Python plugins
87 For the simple case, I've tried the following:
89 [[!template id=gitbranch branch=schmonz/external-plugin-loading author="[[schmonz]]"]]
91 - In `IkiWiki::Plugin::external::import()`, capture stderr
92 - Before falling off the end of `IkiWiki::Plugin::external::rpc_call()`,
93   if the command had been 'import' and stderr is non-empty, throw
94   an exception
95 - In `IkiWiki::loadplugin()`, try/catch/throw just like we do with
96   regular non-external plugins
98 With these changes, we have a test that fails when an external
99 plugin can't be loaded (and passes, less trivially, when it can).
100 Huzzah! (I haven't tested yet whether I've otherwise completely
101 broken the interface for external plugins. Not-huzzah!) --[[schmonz]]