doc/forum/ikiwiki_development_environment_tips.mdwn

   1 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).
   2
   3 Does anyone have a comfortable setup or tips they would like to share? -- [[Jon]]
   4
   5 > 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]]
   6
   7 >> I think this suffers from two problems. Firstly, unless you are tracking git
   8 >> master in your existing wiki, there's the possibility that your plugin will
   9 >> not work with a more modern version of ikiwiki (or that it would benefit
  10 >> from using a newly added utility subroutine or similar).
  11
  12 >>> Unlikely. I don't make changes to the plugin interface that break
  13 >>> existing plugins. (Might change non-exported `IkiWiki::` things
  14 >>> from time to time.) --[[Joey]]
  15
  16 >> Second, sometimes I
  17 >> find that even writing a plugin can involve making minor changes outside of
  18 >> the plugin code (bug fixes, or moving functionality about). So, I think
  19 >> having some kind of environment built around a git checkout is best.
  20 >>
  21 >> However, this does not address the issue of the tedium writing/maintaining a
  22 >> setup file for testing things.
  23 >>
  24 >> I think I might personally benefit from a more consistent environment (I
  25 >> move from machine-to-machine frequently). -- [[Jon]]
  26
  27 > If you set `libdir` to point to a checkout of ikiwiki's git repository,
  28 > it will override use of the installed version of ikiwiki, so ikiwiki will
  29 > immediatly use any changed or new `.pm` files (with the exception of
  30 > IkiWiki.pm), and you can use git to manage it all without an installation
  31 > step. If I am modifying IkiWiki.pm, I generally symlink it from
  32 > `/usr/share/perl5/IkiWiki.pm` to my git reporisitory. Granted, not ideal.
  33 >
  34 > I often use my laptop's local version of my personal wiki for testing.
  35 > It has enough stuff that I can easily test most things, and if I need
  36 > a test page I just dump test cases on the sandbox. I can make
  37 > any changes necessary during testing and then `git reset --hard
  38 > origin/master` to avoid publishing them.
  39 >
  40 > If the thing I'm testing involves templates, or underlays,
  41 > I will instead use ikiwiki's `docwiki.setup` for testing, modifying it as
  42 > needed, since it is preconfigured to use the templates and underlays
  43 > from ikiwiki's source repository.
  44 > --[[Joey]]