summaryrefslogtreecommitdiff
path: root/doc/forum/ikiwiki_development_environment_tips.mdwn
blob: 32da4a1cd3ea4528e11410b4dcbc8976c450ee13 (plain)

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). 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]]