Powerline.bash, le retour !

Cet article a été publié il y a 4 ans 20 jours, il est donc possible qu’il ne soit plus à jour. Les informations proposées sont donc peut-être expirées.

Pour ceux qui lisent le blog depuis un moment, vous savez que j’utilise Powerline pour décorer mon shell, ainsi que celui de mes machines virtuelles à la maison. Dans l’ensemble j’en suis très content, mais le projet qui m’avait lancé sur la personnalisation de mon shell, powerline.bash, est revenu sous mes yeux, et oui, j’ai craqué, j’ai décidé de basculer dessus. Voyons donc pourquoi.

Si vous avez relu mon billet d’origine, l’installation de Powerline, notamment pour avoir un statut git assez visuel est assez lourde, en gros, en plus des paquets powerline et powerline-fonts, il me faut en plus un paquet pip et une configuration maison plutôt chargée à pousser. Autant dire que le contenu du playbook ansible pour déployer tout ça est assez fat, mais bon, c’est pas non plus la mort.

Powerline a ses propres problèmes, et certains m’avaient d’ailleurs été relevés. Le principal, c’est la latence. Il arrive parfois qu’il mette un temps visible à rendre la main, ouvrir un nouveau shell, et le problème empire quand votre CPU est déjà particulièrement chargé comme c’est souvent le cas dernièrement sur mon laptop du boulot. J’ai en plus eu des soucis à l’époque de la bascule Python 3.7 > 3.8 sous Manjaro, ce qui m’avait poussé à devoir tout refaire (en gros j’avais plus de prompt le temps que je corrige). Je n’ai jamais réussi non plus à l’avoir sur deux lignes, et plusieurs tentatives pour personnaliser plus avant se sont toujours soldées par des échecs. Je ne pense pas être plus bête qu’un autre, mais là quand même… Il y a certainement d’autres contrariétés qui ne me reviennent pas en tête là tout de suite, mais voilà, j’ai été donc frustré plus d’une fois avec son utilisation.

« Ha, ha, ha, ha, staying alive… »

Et au gré de mes flux RSS, Etienne Bersac, le développeur de powerline.bash, a fait un journal sur linuxfr pour discuter des mises à jour. C’était l’occasion de découvrir que contrairement à ce que je pensais, je n’avais pas activé les notifications sur le dépôt, ça m’apprendra à être plus vigilant. Donc, depuis le temps, il y a eu pas mal de petits raffinements et de corrections, de nouveaux segments, via des contributions externes, et celui sur git a bien évolué. C’est beaucoup plus intéressant désormais.

J’ai donc retesté le bousin, l’installation et la configuration sont toujours aussi simples, ça tient à un git clone et l’ajout de deux lignes dans le bash_aliases. Dans mon cas évidemment, ça demande aussi de virer/commenter les lignes nécessaires à Powerline.

Je vais la faire courte, j’ai tout de suite été conquis. Certes, les détails concernant le statut du dépôt git sont un peu moins fournies (j’avais le nombre de fichiers avec leur statut quand le dépôt n’était pas à jour, ainsi que le nombre de commits à pousser), mais c’est désormais plus parlant, les couleurs sont mieux choisies, on voit qu’on a des trucs à pousser, il y a le support de plus d’icônes. Et c’est finalement largement suffisant pour éviter de lancer des commandes sans avoir bien vérifié le statut du dépôt auparavant, ça économise pas mal de commandes git status, toujours bon à prendre.

Dossier, venv python, statut git, tout ce qu’il faut quoi 🙂

Quant à la vitesse de chargement et de réponse, c’est évidemment le jour et la nuit. J’ai donc entrepris de rebasculer mon profil dessus sur tous mes serveurs. l’occasion de reprendre mes playbooks pour les remettre au gout du jour, cela faisait un moment qu’ils n’avaient pas été lancés, et j’ai également découvert plusieurs manques ou faiblesses (genre le playbook qui supprime la ligne pour charger acme.sh sur le bastion…). Petite particularité par rapport à la doc, j’ai opté pour un déploiement du dépôt dans /opt, comme ça il n’est cloné qu’une fois pour tous les utilisateurs que je modifie. Le module git d’ansible se chargera des pull la prochaine fois, et voilà.

Et je pense que je vais envisager de le pousser aussi sur mes serveurs « publics », comme celui que j’utilise pour ce blog (qui va vraiment avoir besoin qu’on lui refasse une beauté, ça devient intenable).

En tout cas, c’est du beau boulot, encore merci à Etienne, ainsi qu’aux contributeurs qui sont mentionnés dans le README. Je ne dis pas que j’en ferai partie dans un futur proche, mais j’avais déjà participé à l’époque en terme de remontée de bug sur Ubuntu 16.04 – eh oui, tant qu’il est supporté, on doit le prendre en compte, même s’il sent vraiment la naphtaline maintenant-, et j’ai le segment Kubernetes à tester sur le pc du boulot (pas encore à la maison, je pense qu’en termes de priorité la VM du blog est prioritaire). Donc y’a peut⁻être encore des trucs à remonter ou contribuer 🙂