diff options
author | Jonas Smedegaard <dr@jones.dk> | 2010-08-27 10:01:58 +0200 |
---|---|---|
committer | Jonas Smedegaard <dr@jones.dk> | 2010-08-27 10:01:58 +0200 |
commit | f398ad035b973608d380c9939ea845d8e2a0cdc2 (patch) | |
tree | 1ba1a0c94e375ab8ed609eaa57a542c6b87de5a8 /doc/forum/ikiwiki_development_environment_tips.mdwn | |
parent | 958e5735c946263a111420fe47abe58782581e8c (diff) | |
parent | 6d213a0c739d5b34357b01a616f99197eeba6ad9 (diff) |
Merge branch 'master' of git://git.ikiwiki.info
Diffstat (limited to 'doc/forum/ikiwiki_development_environment_tips.mdwn')
-rw-r--r-- | doc/forum/ikiwiki_development_environment_tips.mdwn | 44 |
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]] |