0007 — Bash plutôt que PowerShell
Contexte
- L'environnement principal de développement repose sur WSL, qui fournit un Linux natif pour les workflows du hub.
- Les scripts existants et les outils d'automatisation sont exécutés depuis les shells Linux disponibles dans WSL.
- Windows reste l'OS hôte, mais ne sert qu'à lancer VS Code et gérer les fichiers partagés, pas à exécuter les scripts critiques.
Décision
- Utiliser Bash comme langage principal pour les scripts et l'automatisation du hub.
- Écrire et maintenir les scripts dans un format POSIX/Bash compatible Linux.
- Limiter l'usage de PowerShell aux tâches strictement spécifiques à Windows ou aux intégrations impossibles à réaliser en Bash.
Raisons
- Cohérence avec l'environnement WSL déjà adopté pour le développement quotidien.
- Portabilité directe vers d'autres distributions Linux ou environnements distants.
- Compatibilité immédiate avec les outils CLI standards (GNU, Docker, package managers, etc.).
- Simplicité et expressivité des scripts shell pour l'orchestration et les tâches répétitives.
- Alignement avec les pratiques modernes d'automatisation et les workflows DevOps dominés par Bash.
Conséquences
Positives
- Scripts portables et réutilisables dans toute cible Linux ou conteneurisée.
- Cohérence globale de l'environnement technique pour l'équipe et les machines.
- Intégration fluide avec l'écosystème Unix (pipes, make, task runners, Git hooks).
- Automatisation simplifiée grâce aux utilitaires standard disponibles par défaut sous WSL.
Négatives
- Intégration native Windows (COM, modules PowerShell) moins directe.
- Nécessité pour chaque contributeur de maîtriser Bash et les outils Unix de base.
- Certaines tâches spécifiques à Windows peuvent demander des wrappers ou scripts complémentaires.
Alternatives considérées
- PowerShell comme standard : rejeté car incohérent avec l'exécution Linux-first imposée par WSL.
- Scripts hybrides Bash + PowerShell : rejetés pour éviter la complexité et les dépendances croisées.
Statut
Accepté.