102 lines
3.9 KiB
Markdown
102 lines
3.9 KiB
Markdown
## 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 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 [[!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 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 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]]
|