I haven't settled on a comfortable/flexible/quick development environment for hacking on ikiwiki. The VM I host my web pages on is not fast enough to use for RAD and ikiwiki. For developing plugins, it seems a bit heavy-weight to clone the entire ikiwiki repository. I haven't managed to get into a habit of running a cloned version of ikiwiki from it's own dir, rather than installing it (If that's even possible). The ikiwiki site source (source ./doc) is quite large and not a great testbed for hacking (e.g. if you are working on a plugin you need a tailored test suite for that plugin).

Does anyone have a comfortable setup or tips they would like to share? -- Jon

I've just been setting libdir in an existing wiki's setup file. When the plugin's in a decent state, I copy it over to a git checkout and commit. For the plugins I've been working on (auth and VCS), this has been just fine. Are you looking for something more? --schmonz

I think this suffers from two problems. Firstly, unless you are tracking git master in your existing wiki, there's the possibility that your plugin will not work with a more modern version of ikiwiki (or that it would benefit from using a newly added utility subroutine or similar).

Unlikely. I don't make changes to the plugin interface that break existing plugins. (Might change non-exported IkiWiki:: things from time to time.) --Joey

Second, sometimes I find that even writing a plugin can involve making minor changes outside of the plugin code (bug fixes, or moving functionality about). So, I think having some kind of environment built around a git checkout is best.

However, this does not address the issue of the tedium writing/maintaining a setup file for testing things.

I think I might personally benefit from a more consistent environment (I move from machine-to-machine frequently). -- Jon

If you set libdir to point to a checkout of ikiwiki's git repository, it will override use of the installed version of ikiwiki, so ikiwiki will immediatly use any changed or new .pm files (with the exception of IkiWiki.pm), and you can use git to manage it all without an installation step. If I am modifying IkiWiki.pm, I generally symlink it from /usr/share/perl5/IkiWiki.pm to my git reporisitory. Granted, not ideal.

I often use my laptop's local version of my personal wiki for testing. It has enough stuff that I can easily test most things, and if I need a test page I just dump test cases on the sandbox. I can make any changes necessary during testing and then git reset --hard origin/master to avoid publishing them.

If the thing I'm testing involves templates, or underlays, I will instead use ikiwiki's docwiki.setup for testing, modifying it as needed, since it is preconfigured to use the templates and underlays from ikiwiki's source repository. --Joey

I work with Ikiwiki from the git checkout directory the following way.

• instead of running ikiwiki, I wrote the following mykiwiki shell script, that also allows me to use my custom lib-ifited multimarkdown:

#!/bin/sh

MMDSRC="$HOME/src/multimarkdown/lib"
IKIWIKISRC="$HOME/src/ikiwiki"
PLUGINS="$HOME/src/ikiplugins"

/usr/bin/perl -I"$MMDSRC" -I"$IKIWIKISRC/blib/lib" -I"$PLUGINS" "$IKIWIKISRC/ikiwiki.out" -libdir "$IKIWIKISRC" "$@"

• I also have an installed ikiwiki from Debian unstable, from which I only use the base wiki, so my .setup has the following configs:

# additional directory to search for template files
templatedir => '/home/oblomov/src/ikiwiki/templates',
# base wiki source location
underlaydir => '/usr/share/ikiwiki/basewiki',
# extra library and plugin directory
libdir => '/home/oblomov/src/ikiwiki',

Hope that helps --GB