summaryrefslogtreecommitdiff
path: root/doc/forum/ikiwiki_development_environment_tips.mdwn
diff options
context:
space:
mode:
authorintrigeri <intrigeri@boum.org>2010-06-25 14:38:37 +0200
committerintrigeri <intrigeri@boum.org>2010-06-25 14:38:37 +0200
commit9f401d6617a11efcedda1c956b2ccea061a7540f (patch)
treea5648589b38487427a58a7ebacfdc036a5dd102a /doc/forum/ikiwiki_development_environment_tips.mdwn
parent73f4a8835876c8cb07808367cd72d9ae972893e8 (diff)
parent71950b2ae5ff6fd3b631c5504455cc07699b1c11 (diff)
Merge remote branch 'upstream/master' into prv/po
Conflicts: IkiWiki/Plugin/po.pm
Diffstat (limited to 'doc/forum/ikiwiki_development_environment_tips.mdwn')
-rw-r--r--doc/forum/ikiwiki_development_environment_tips.mdwn44
1 files changed, 44 insertions, 0 deletions
diff --git a/doc/forum/ikiwiki_development_environment_tips.mdwn b/doc/forum/ikiwiki_development_environment_tips.mdwn
new file mode 100644
index 000000000..91ccc6d6e
--- /dev/null
+++ b/doc/forum/ikiwiki_development_environment_tips.mdwn
@@ -0,0 +1,44 @@
+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]]