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

ArchDocumentalist : avoir la doc sous le coude pour votre archlinux

Quelque soit la distribution, il peut être utile d’avoir une copie de sa documentation sous le coude, au cas où. En effet, on peut se retrouver parfois sans connection internet et souhaiter jeter un coup d’oeil dans la documentation.

Avec le wiki de archlinux.fr, le wiki d’archlinux.org est une vraie mine d’or. la propriété de ce dernier wiki est d’avoir à la fois la documentation en anglais mais aussi (lorsqu’elles sont disponibles) les traductions en d’autres langues. Je dois dire que la structure est efficace. Les pages de bases sont en anglais et les traductions ont pour titre

Page_title_(Français)

Des redirections peuvent exister pour traduire les titres…

Arch-wiki-docs

Dans le dépôt community, il existe un paquet qui permet d’obtenir une copie de la documentation sur son disque. C’est arch-wiki-docs. Ce paquet contient déjà la doc, et il est mis à jour régulièrement.

Formidable me direz-vous… sauf que ce paquet contient toutes les langues, donc trop de choses comme l’on fait remarqué certaines personnes sur ce fil de discussion (anglais).

ArchDocumentalist

Le code original était un mélange de perl et de script shell. J’ai donc pris l’initiative de réécrire un code, entièrement en perl cette fois ci (fabuleux langage au passage ! ). Le dépôt git se trouve là et j’ai empaqueté le script dans AUR. Donc

yaourt -S archdocumentalist

pour l’installer.

L’utilisation est fort simple :

archdocumentalist.pl FR /tmp

et le répertoire /tmp/arch-wiki-FR contiendra les pages. Ouvrez index.html. Vous pouvez générer d’autres langues. Ex : remplacez FR par EN.

A la limite, la doc peut être mise à jour tous les mois par une tâche cron.

PS : je conseille d’installer un navigateur en console pour lire la doc (si tout venait à lâcher ce qui arrive une fois par siècle.)
PPS : évitez /tmp comme répertoire de stockage d’une doc