wiki versionné avec git

Dans la vie numérique, j’aime git et j’aime les wiki que ce soit pour un usage collaboratif ou personnel.

Celles et ceux d’entre vous qui me suivent savent que j’utilise zim afin de conserver mes notes privées ou n’ayant aucun intérêt à être divulguées. Zim se définit comme un wiki de bureau.

Il se trouve que je viens d’avoir un nouveau besoin : répertorier des petits bouts de code présentant des syntaxes ou des usages de bibliothèques que j’ai cherché au moins une fois. Zim ne propose pas de coloration syntaxique pour ça et la demande de colorisation de texte est un bug ouvert (d’après mon souvenir).

Bref, toujours curieux, toujours prêt à tester de nouvelles solutions, je me suis mis à chercher des wikis en ligne avec git comme gestionnaire de version. En effet, je veux retrouver les avantages que j’ai avec Zim à savoir :

•   reposer sur des fichiers textes avec de préférence une syntaxe non ésotérique

•   être accessible hors ligne, ce qui signifie avoir une copie locale complète

Ce dernier point étant important, car si mon serveur tombe ou si je n’ai plus de moyen de me connecter, je veux toujours accéder à mes données.

J’ai trouvé et testé deux solutions. Il en existe peut être d’autres qui m’ont échappé. La première se nomme gitit. C’est codé en haskell, ca ressemble beaucoup à mediawiki. L’installation sur un serveur debian s’est passée sans encombre à l’aide du paquet fourni et de la doc. J’ai été vraiment séduit à l’usage notamment par le support de différents langages de balisage léger, l’export dans N formats (epub, pdf, tex et j’en passe), c’est pandoc qui est derrière, donc du costaud. A noté aussi le support mathml et la possibilité de faire des slides en html5 (j’ai trouvé ça génial).
J’ai été déçu quand je me suis rendu compte que le support coloration syntaxique demandait de recompiler le logiciel (sauf si j’ai raté quelque chose, le paquet debian ne semble pas avoir ce support). ce n’est pas insurmontable, mais sur le coup, je n’ai pas eu envie.

Retour moteur de recherche et je suis tombé sur ikiwiki. Après un coup de ménage sur le serveur, j’installe donc ce palindrome. Là aussi, paquet + doc rendent ça très facile. Au passage, heureusement que les lib perl sont empaquetées, il y en a une belle quantité.
Je n’ai pas pris l’installation manuelle, la version "automatique" + ajustement ultérieur m’a semblé suffisant. L’interface par défaut est moins sexy que gitit, mais on peut trouver quelques css. Il existe aussi une foule de greffons dont un qui gère des refs via bibtex. Pas encore testé, mais ça m’intéresse grandement. Coté fonctionnalité, j’ai presque l’impression que c’est le négatif que gitit. J’aimerai voir tous les avantages que j’ai cité dans gitit chez ikiwiki. Notamment, pas de mathml mais un greffon qui fait du dvipng
Ikiwiki fait un build des pages grâce à un hook git, donc dès que vous poussez votre version, ça reconstruit un html statique à partir du (des) fichier(s) modifié(s) servi par votre serveur web. Etant donné les langages et le plus grand nombre de greffons, ikiwiki remporte mon intérêt. En effet, je peux coder un peu en perl et j’ai vu qu’il est possible de coder des greffons en python.

Une remarque importante est que ikiwiki peut être utilisé comme un blog statique. J’ai remarqué qu’un certain nombre d’auteurs retournait sur ce genre de solution après une expérience de CMS comme wordpress. Il est vrai que la légèreté (important pour les lecteurs aux faibles débits et les auto-hébergés) et l’atout rédactionnel déporté sont intéressants. L’intérêt que je verrai à ikiwiki pour cet usage serait les commentaires gérés sans service externe (cf ce blog à titre d’exemple).

Même si je n’ai pas encore rendu Zim, je me rend compte que ikiwiki serait plus adapté à mes usages. Zim m’aide beaucoup en tant que wiki, mais peu en terme d’utilisation et de fonctionnalité. Je n’aime pas l’éditeur d’équation, l’import d’image ou l’absence de support syntaxique.

Si certain(e)s ont un expérience dans ce domaine, je suis preneur ; autrement je vous laisse décrouvrir