Commit 75af2156 authored by wbar's avatar wbar
Browse files

update a propos page + begin explanations on why I choose Hugo for this new version

parent e28abb27
......@@ -27,6 +27,10 @@ et [là (pour le layout)](https://framagit.org/wbar/bwog-notes-v2/tree/master/la
Le tout est écrit en Markdown et versionné à l'aide de Git.
[Une version des sources](https://framagit.org/wbar/bwog-notes-v2) est disponible sur mon dépôt Framagit.
Dans la version d'avant, ce blog était généré avec [Pelican](https://blog.getpelican.com/).
Le thème était le même, vous pouvez toujours trouver les anciennes sources [sur ce dépôt](https://framagit.org/wbar/bonefire).
[Cet article]({{< ref "migration-pelican-hugo.md">}}) détaille les raisons et donne quelques observations.
## Partage ##
Comme indiqué sur chaque page,
......
+++
Categories = [""]
Tags = ["blog","hugo", "pelican"]
title = "Migration de Pelican à Hugo"
slug = "Migration Pelican Hugo"
date = 2019-10-21T15:11:45+02:00
draft = true
+++
Ca y est !
Voici la nouvelle version du BWog-notes ! Youpi !
En plus du changement d'hébergement, la pile technique a changé.
Auapravant, le générateur était [Pelican](https://blog.getpelican.com/), maintenant c'est [Hugo](https://gohugo.io/).
Voici mes raisons, et mes observations liées.
<!--more-->
## Déjà, pourquoi un site statique ?
J'ai arrêté les sites persos dynamiques voilà un moment déjà.
Flemme de maintenir, flemme d'apprendre à utiliser des frameworks, flemme de gérer des BDD et des quotas d'espace disque, etc.
Et à l'époque, pas assez de sous / connaissances pour me lancer sur mon propre hébergement.
Je n'ai toujours été que sur des espaces mutualisés gratuit, sans réel nom de domaine (jusqu'à présent).
Dans ces conditions, le plus simple était donc, pour rester en ligne, d'avoir un site statique.
## Du coup, c'était comment avant ?
Déjà, c'était pas mieux.
J'avais bricolé un ensemble de scripts python tout gros, tout moche, pas optimisé, qui me gobait des pages html fabriquées à la main,
et qui assemblait le tout pour en faire un site complet, directement hébergeable, sans prise de tête autre que celle de bien écrire le html
(manuellement, à chaque fois, sur chaque page).
Rustique, artisanal quoiqu'un peu déguelasse, mais ça faisait le boulot.
M'enfin je me rendais bien compte que c'était pas terrible, ça me demandait aussi bien du temps pour la rédaction, que la mise en page.
Et oui, y'avait pas de templates ! Ni aucune fonction « moderne » pour itérer magiquement sur le contenu.
Sans compter les nombreux bugs qui freinaient le processus.
J'ai voulu tout ré-écrire de zéro, mais je me suis plutôt demandé s'il n'existait pas quelque chose de déjà fait, et surtout mieux.
Vint alors Pelican sur la table.
C'était en python, mon langage phare de l'époque[^1], il y avait des templates, et ça semblait plutôt facile à prendre en main.
Ni une, ni deux, j'adopte !
Et je lance le BWog-notes par la même occasion.
## Pourquoi changer de générateur ?
Et bien parce que c'était cool, mais pas top !
Même si les virtualenvs, ça fait grave le café, pour avoir un Pelican fonctionnel, il faut installer Pelican (`pip install pelican`),
et rapidement d'autres trucs.
Exemple, rien que pour rédiger en markdown, faut rajouter `pip install Markdown`.
Ensuite, pour les bouts de code `pip install pygments`, et lui faire générer un CSS à inclure sur le site.
Faut pas oublier d'activer le virtualenv avant ça d'ailleurs, et même pour chaque rédaction.
Et puis ça génère ouate mille fichiers de conf, d'automatistation de génération, etc.
Heureusement, il existe plein de plugins pour étendre les fonctionnalités, mais bon, pour certains, ils sont quand même restreint.
Et c'est pas pour jeter la pierre aux mainteneurs, je sais que ça prend du temps, mais ils sont souvent datés.
Par exemple pour les figures avec légende, et lien cliquable vers la grande version de l'image,
j'ai du [bidouiller le plugin figureAltCaption]({{< ref "pelican-python-markdown-images-dans-bateau.md" >}}).
Du coup, même si j'ai passé beaucoup de temps avec Pelican, en étant très content hein, j'ai fini par avoir des envies de changement.
## Le changement de générateur
J'ai migré récemment Pintes et Growls (lien dans la page « À propos »), et j'en ai profité pour tester Hugo.
Pourquoi ce générateur ?
Au delà du bête « pourquoi pas », c'est surtout parce que dans mes flux RSS, il y a plusieurs personnes qui l'utilisent.
J'avais donc déjà sous le coude des exemples et des retours d'expérience.
Alors, l'installation par rapport à Pelican ?
Et bien installer le binaire (`pacman -Sy hugo` pour moi) et ... c'est tout !
Et maintenant, et bien pour moi, à l'utilisation, c'est plus simple.
Moins d'étapes (surtout dans mes scripts de synchro / publication), plus rapide, aucune dépendance, tout est inclus.
Et si on veut faire ajouter dans une page quelque qui n'est pas prévu à la base par le Markdown (même exemple, les figures cliquables) :
zou ! un `shortcode` (mini template html dans les templates qu'on appelle avec une petite ligne qu'on définit nous même) et c'est parti !
## Le nouveau processus
Avant c'était :
- `source .venv/bin/activate`
- `./create_article.sh`[^2]
- rédaction
- `pelican build`
- regarder le résultat
- `cd content`
- `git add . && git commit -m "nouvel article" && git push origin master`
- `cd ..`
- `./publish.sh`
- vérifier en ligne le résultat
- `deactivate`
Maintenant c'est :
- `hugo new post/nouvel-article.md`
- rédaction
- `hugo serve`
- vérification
- `git add . && git commit -m "nouvel article" && git push origin master`
- `./publish.sh`
- vérifier en ligne le résultat
Plus besoin du script de creation d'article, hugo, via un système de templates d'articles (appelée `archetypes`),
génère un fichier avec préambule et éventuellement début de contenu.
Le script de publication en ligne est également plus court.
Et encore, je pourrais même virer une étape en mettant un `git hook` pour publier dès que je pousse les sources.
## Conclusion
Alors sans mauvaise foi, ça va beaucoup plus vite, que ce soit pour moi, ou pour la génération et la maintenance du site.
**MAIS** il faut noter que l'investissement technique (pour moi) est bien plus gros à l'entrée pour hugo.
Il a fallut recréer le thème et les templates[^3], des `layouts` dans le jargon hugo, et c'est pas facile à prendre en main,
même en reprenant une structure déjà existante.
Il y a eu un gros temps d'adaptation aux fonctions des templates, à la logique d'organisation des fichiers,
ainsi qu'un certain temps à investir pour convertir / corriger les articles.
Une fois tout ça fait, je me sens carrément plus à l'aise maintenant.
A vous de jouer, vous avez tout en main pour choisir ! Alors, n'attendez plus, lancez-vous !
[^1]: Entre nous, ça l'est toujours dès que je dois prototyper un truc, ou scripter plus haut niveau que de la bête admin sys.
[^2]: Un script perso qui pré-génère un squelette d'article.
[^3]: Pas envie de prendre un thème tout fait, j'avais déjà le mien après tout.
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment