Comment gérer vos fichiers .dotfiles avec GNU Stow étape par étape

Si vous utilisez Linux, macOS ou Termux sur Android Chaque jour, tôt ou tard, vous finissez par accumuler un tas de fichiers de configuration éparpillés un peu partout dans votre système. Répertoire personnel : .zshrc, .bashrc, .config, nvim, Hyprland, etc. Quand on n'a qu'un seul ordinateur, on peut s'en sortir, mais dès qu'on travaille avec plusieurs ordinateurs ou serveurs, maintenir tout cela à jour est une toute autre histoire.

Dans ce contexte, les éléments suivants entrent en jeu. GNU Stow, un gestionnaire de liens symboliques qui est devenu l'une des méthodes les plus claires, simples et réversibles pour gérer les fichiers de configuration. Ce n'est pas la seule approche possible (il existe des alternatives comme les dépôts Git nus, yadm, Chezmoi, Dotbot…), mais sa philosophie minimaliste est idéale si vous recherchez un outil puissant et facile à utiliser.

Qu'est-ce que GNU Stow exactement et pourquoi est-il utile pour gérer les fichiers .dotfiles ?

GNU Stow est, à l'origine, un « gestionnaire de ferme de liens symboliques ».Un outil conçu pour organiser plusieurs « paquets » de fichiers dans un emplacement et les exposer dans un autre répertoire via des liens symboliques. Bien qu'il ait été initialement conçu pour la gestion des installations logicielles locales, la communauté l'a rapidement adopté pour la gestion des fichiers de configuration (dotfiles) car il s'y intègre parfaitement.

L'idée de base est très simple : vous enregistrez tous vos paramètres dans un seul fichier. dépôt central (par exemple ~/dotfiles)Ces fichiers sont structurés comme s'ils étaient destinés à votre répertoire personnel, et Stow se charge de créer des liens symboliques depuis ce répertoire vers ces fichiers. Vous pouvez ainsi les versionner avec Git, les cloner sur plusieurs machines et reproduire votre environnement en une ou quelques commandes.

Quelque chose d'important: Stow n'est pas un « outil de gestion de fichiers de configuration » au sens strict.Il ne stocke pas d'état propre, ne gère aucune base de données, n'utilise aucun modèle ni aucun chiffrement. Il se contente de créer et de supprimer des liens symboliques en suivant une arborescence de répertoires. C'est précisément ce qui le rend si facile à comprendre et à restaurer.

Cette philosophie minimaliste contraste avec des solutions plus complexes comme Chezmoi, qui ajoutent des modèles, la gestion des secrets, l'intégration avec les gestionnaires de mots de passe et un flux de travail plus automatisé. Avec Stow, vous êtes aux commandes : tout se trouve dans le système de fichiers et votre dépôt Git., sans couches intermédiaires.

Avantages de l'utilisation de Stow par rapport aux autres méthodes de gestion des fichiers de configuration

Avant que Stow ne devienne populaire, beaucoup de gens géraient leurs fichiers de configuration à l'aide des commandes « cp » et « mv ».Les configurations étaient copiées manuellement d'un ordinateur à l'autre, ou bien un référentiel était maintenu et nécessitait des mises à jour constantes. Il était facile de se retrouver avec plusieurs versions d'un même fichier et de ne plus savoir laquelle était réellement utilisée.

Avec Stow, tous les fichiers « réels » se trouvent dans votre répertoire dotfiles et Votre répertoire $HOME ne contient que des liens symboliquesCela signifie que lorsque vous modifiez, par exemple, le fichier ~/.zshrc, vous modifiez en réalité le fichier situé dans votre dépôt. Il n'y a pas de doublons, pas de désynchronisation et vous n'avez pas besoin de vous souvenir de ce qu'il faut copier ni où.

Un autre avantage évident est la réversibilité : Si vous souhaitez annuler les actions de Stow, exécutez simplement « stow -D package ». Dans votre dossier dotfiles, supprimez tous les liens symboliques créés pour ce paquet. Cela ne supprime pas vos configurations (qui restent dans le dépôt), mais uniquement les liens symboliques vers le paquet cible.

De plus, Stow fonctionne très bien avec Git : Vous pouvez versionner ~/dotfiles comme un dépôt normalVous pouvez effectuer des commits, créer des branches, utiliser GitHub ou GitLab comme sauvegarde, etc. Stow ignore automatiquement le dossier .git lors de la génération des liens, vous ne risquez donc pas de saturer votre répertoire $HOME avec des fichiers Git internes.

Enfin, contrairement à d'autres outils plus lourds, Stow est généralement disponible sur toutes les distributions Linux et même sur macOS via Homebrew.Il s'agit essentiellement d'un scénario Écrit en Perl avec très peu de dépendances et fonctionne dans n'importe quel environnement UNIX.

Alternatives courantes : Git bare, yadm, Chezmoi, Dotbot…

Lorsqu'on envisage sérieusement la gestion des fichiers de configuration, la même liste d'options apparaît généralement : Dépôt Git « nu », yadm, Dotbot, Chezmoi, et StowChaque approche a son propre style et son propre public, il est donc important de situer Stow au sein de cet écosystème.

La méthode de dépôt Git nu Cela implique d'initialiser un dépôt sans répertoire de travail associé et d'utiliser des alias Git pour que $HOME serve de répertoire de travail. Avantages : absence de liens symboliques, Git agit directement sur vos fichiers et la syntaxe est très simple. De nombreux utilisateurs se disent surpris de la facilité avec laquelle ils ont pu suivre un tutoriel de type « DT » et obtenir un résultat fonctionnel sans toucher aux liens symboliques.

En outre, Chezmoi se concentre entièrement sur la gestion avancée des fichiers dotfile.Ses fonctionnalités incluent : des modèles pour gérer les différences entre machines, l’intégration avec les gestionnaires de mots de passe, le chiffrement des fichiers avec GPG ou AGE, des points d’extension pour exécuter des scripts lors de l’installation, une prise en charge multiplateforme robuste, et bien plus encore. Il est idéal si vous avez besoin de : gestion des secrets, prise en charge de nombreux systèmes différents ou automatisation d'installations complexes.

Stow se situe à l'extrême opposé : Il ne connaît rien aux secrets, aux modèles ou aux scripts.Il crée simplement des liens symboliques propres. Pour de nombreux utilisateurs, c'est un avantage : moins de connaissances à acquérir, un comportement moins opaque et une plus grande transparence. Si vous avez besoin d'une logique conditionnelle complexe, Chezmoi est probablement plus adapté ; si vous souhaitez simplement organiser vos configurations sans complications, Stow est un classique très fiable.

Il existe également des outils comme Yadm ou Dotbot, qui automatisent des tonnes de tâches (y compris l'exécution de scripts post-installation, le clonage de dépôts, l'installation de paquets, etc.). Malgré cela, de nombreux développeurs privilégient encore Stow car il est facile à auditer, s'intègre parfaitement aux flux de travail Git existants et s'adapte sans problème aux configurations minimalistes comme aux environnements de bureau plus exigeants.

Approches organisationnelles : dépôt unifié vs dépôt basé sur les paquets

Lorsque vous commencez à utiliser Stow, l'une des premières décisions que vous devez prendre est Comment structurer votre dépôt de fichiers de configuration ?De manière générale, il existe deux modèles populaires : l’approche unifiée et l’approche par paquets.

Dans le modèle unifié, votre dépôt de fichiers de configuration a pratiquement la même forme que votre répertoire $HOME : des fichiers comme .bashrc ou .zshrc à la racine, et des dossiers comme .config/nvim ou .config/lazygit à l'intérieurQuelque chose comme ceci :

dotfiles-unifiés/
├── .bash_aliases
├── .bash_completion/
│ └── alacritty.bash
├── .bashrc
└── .config/
├── lazygit/config.yml
└── nvim/…

Avec cette conception, vous accédez au dossier du dépôt, vous exécutez ranger. et soudain, Tous vos paramètres sont liés à votre répertoire $HOMEC'est incroyablement pratique lorsque vous souhaitez cloner l'intégralité de votre environnement sur une nouvelle machine en une seule commande et que vous n'avez pas besoin de beaucoup de différenciation entre les systèmes.

L'approche par paquets fonctionne différemment : Vous créez un sous-répertoire par « module » ou application.Par exemple, un répertoire pour bash, un autre pour nvim, un autre pour lazygit, un autre pour zsh, un autre pour Hyprland, etc. Chaque répertoire contient les fichiers avec le chemin complet qu'ils auraient dans votre répertoire personnel ($HOME). Quelque chose comme :

paquets dotfiles/
├── bash/
│ ├── .bash_aliases
│ ├── .bash_completion/alacritty.bash
│ └── .bashrc
├── lazygit/.config/lazygit/config.yml
└── nvim/.config/nvim/…

Ce système vous permet de choisir les paquets à « activer » sur chaque machine : Sur une machine, vous exécutez « stow bash nvim lazygit », sur une autre peut-être « stow zsh nvim ».Ceci est très utile lorsque vous travaillez avec plusieurs distributions (par exemple, Arch sur un PC et Fedora sur un autre) ou avec différents shells (fish sur une machine, bash sur une autre) et que vous souhaitez tout conserver dans un seul dépôt, mais choisir ce qu'il faut appliquer dans chaque environnement.

Le hic ? C'est un peu plus complexe : « Stow » ne suffit plus. Voilà, c’est tout ; il vous suffit de vous souvenir des paquets dont vous avez besoin.Vous pouvez aussi créer un petit script par machine qui appelle Stow avec la combinaison appropriée. Cependant, de nombreux utilisateurs préfèrent ce contrôle précis, surtout s'ils utilisent des logiciels spécifiques sur chaque machine.

Fonctionnement interne de Stow : le concept de « mise en miroir » des répertoires

La clé pour comprendre Stow réside dans son système de structures de répertoires miroirs (mise en miroir de répertoires)Stow ne devine pas les chemins d'accès ; il examine simplement la manière dont les fichiers sont organisés au sein du « paquet » et place les liens symboliques correspondants dans le répertoire de destination.

Par exemple, si une application attend sa configuration dans :

~/.config/ghostty/

Votre module situé dans ~/dotfiles doit avoir exactement ce chemin relatif :

~/dotfiles/ghostty/.config/ghostty/

Tout fichier placé dans ce répertoire (par exemple, un fichier nommé config) sera lié par Stow à son emplacement correct. Ainsi, Ghostty continuera de lire sa configuration depuis ~/.config/ghostty/config, mais ce fichier pointera en réalité vers celui stocké dans votre dépôt.

Ce schéma se répète pour tous les outils : Waybar aurait un fichier de configuration du type ~/dotfiles/waybar/.config/waybar/, Neovim ~/dotfiles/nvim/.config/nvim/Et ainsi de suite. Le processus est extrêmement uniforme, ce qui rend le passage à un plus grand nombre de programmes presque mécanique.

Pour les fichiers de configuration qui résident directement dans $HOME (tels que ~/.gitconfig ou ~/.zshrc), la logique est identique : Dans le package git, vous trouverez un fichier .gitconfig dans le répertoire racine.Stow créera alors le lien dans votre répertoire personnel lorsque vous exécuterez « stow git ».

Étape par étape : configuration d’un dépôt de fichiers de configuration avec Stow

Le flux de travail typique avec Stow est simple et peut être résumé en quelques étapes bien définies, aussi bien sous Linux que sous macOS. L'important est de s'habituer au fait que les fichiers « réels » se trouvent toujours à l'intérieur du dépôt. et non pas dispersés dans toute votre maison.

Pour commencer, créez le répertoire qui accueillera vos fichiers de configuration. Beaucoup de personnes utilisent ~/.dotfiles ou ~/dotfilesLe nom est la chose la moins importante :

mkdir -p ~/.dotfiles
cd ~/.dotfiles

Puis Déplacez vos fichiers de configuration actuels vers le dépôtPar exemple, si vous avez un fichier .bashrc dans votre répertoire personnel et que vous souhaitez le gérer avec Stow, vous pouvez procéder comme suit :

mv ~/.bashrc ~/.dotfiles/.bashrc

Si vous préférez l'approche par paquets, au lieu de laisser le fichier à la racine du dépôt, vous le placerez dans un dossier « bash », en conservant le chemin complet :

mkdir -p ~/.dotfiles/bash
mv ~/.bashrc ~/.dotfiles/bash/.bashrc

La procédure concernant les configurations contenues dans le fichier .config est analogue : Vous reproduisez la structure de répertoires au sein du dépôtPar exemple, pour Neovim, vous pourriez avoir :

mkdir -p ~/.dotfiles/nvim/.config/nvim
mv ~/.config/nvim/* ~/.dotfiles/nvim/.config/nvim/

Une fois les fichiers dans votre dépôt, il est conseillé de supprimer ou de renommer les originaux dans $HOME afin d'éviter les conflits. Stow recréera ensuite les liens symboliques dans les répertoires où les applications s'attendent à trouver leurs configurations.

Installer GNU Stow sur différentes plateformes

L'installation de Stow varie légèrement selon la plateforme, mais dans l'ensemble, elle est extrêmement simple. Sur macOS, il est courant d'utiliser Homebrew., le gestionnaire de paquets le plus répandu sur ce système :

brew install stow

Dans les distributions Linux comme Debian ou Ubuntu, la pratique courante consiste à utiliser apt:

sudo apt install stow

En Arch Linux et ses dérivés, vous pouvez le trouver dans les dépôts officiels et il s'installe avec pacman sans grand mystère :

sudo pacman -S stow

Une fois installée, la commande « stow » se trouve dans votre PATH. Il n'y a pas de démons ni de services en arrière-plan, juste un fichier binaire qui s'exécute lorsque vous en avez besoin.Vous pouvez vérifier que tout fonctionne correctement avec la commande « stow --version » et c'est terminé.

Sur les systèmes où vous utilisez déjà des outils comme Oh My Zsh, Stow s'intègre parfaitement : vous pouvez conserver à la fois le fichier .zshrc et la configuration des plugins et des thèmes dans votre dépôt central et tout appliquer en quelques commandes. De nombreux utilisateurs avec plusieurs Mac Ou encore, en utilisant un mélange de Linux et de macOS, ils affirment que de cette façon, ils parviennent à avoir le même shell et la même invite de commande partout..

Ignorer les fichiers indésirables avec .stow-local-ignore

L'un des atouts de Stow réside dans son système d'ignorance. Par défaut, Stow ignore déjà certains fichiers de contrôle de version typiques comme .git, .gitignore, .gitmodules, les répertoires CVS, RCS, etc. Cependant, il existe des situations où un contrôle plus précis est nécessaire, par exemple sur macOS avec le fameux .DS_Store.

Stow vous permet de créer un fichier appelé .stow-local-ignore Dans le répertoire depuis lequel vous exécutez la commande, ce fichier définit les motifs à ignorer localement. Une fois créé, il remplace la liste d'exclusion par défaut ; vous devez donc ajouter vous-même les motifs à ignorer et inclure les motifs supplémentaires.

Un exemple typique de contenu pour .stow-local-ignore inclurait des commentaires et des modèles pour les conflits CVS, les sauvegardes Emacs, les fichiers de contrôle de version, et à la fin .DS_Store afin que Stow ne se plaigne pas ou n'essaie pas de lier les fichiers générés par le Finder :

# Comentarios y líneas en blanco permitidas
RCS
.+,v
CVS
\.#.+
\.cvsignore
\.svn
_darcs
\.hg
\.git
\.gitignore
\.gitmodules
.+~
\#.*\#
^/README.*
^/LICENSE.*
^/COPYING
.DS_Store

Grâce à cela, vous empêchez Stow d'essayer de créer des liens de fichiers totalement inutiles et Vous évitez ainsi les erreurs agaçantes lors du rangement ou du déballage des colis.Ceci est particulièrement utile si vous parcourez fréquemment votre dépôt à l'aide d'interfaces graphiques qui génèrent des fichiers auxiliaires.

N'oubliez pas que la liste des éléments ignorés par Stow est indépendante du fichier .gitignore que vous utilisez dans votre dépôt : Le premier contrôle ce qui est lié, le second ce qui est versionné.Vous pouvez ainsi affiner le comportement de Stow et de Git.

Utilisation de base de Stow : liaison et dissociation des packages de configuration

Avec tout préparé, les opérations quotidiennes de Stow sont très concises. Vous devez toujours exécuter Stow depuis votre répertoire de dépôt de fichiers de configuration., et non pas depuis votre $HOME ou depuis des routes arbitraires, afin que les routes relatives qu'il génère soient logiques.

Imaginez que vous ayez déjà un module nommé « ghostty » dans ~/dotfiles/ghostty/.config/ghostty avec votre fichier de configuration. Une fois qu’il est dans le dépôt, vous pouvez l’enregistrer avec :

cd ~/dotfiles
stow ghostty

Cette commande crée des liens symboliques sur votre système, reliant ~/.config/ghostty aux fichiers situés dans ~/dotfiles/ghostty/.config/ghostty. Si vous exécutez la commande « ls -l ~/.config/ghostty », vous verrez des champignons (->) indiquant la cible de chaque lien symbolique.vérifier que tout est correctement connecté.

Si vous optez pour une approche unifiée et souhaitez tout relier en même temps, Vous pouvez exécuter « stow . » depuis la racine du dépôtStow interprétera chaque sous-répertoire comme un paquet ou travaillera directement sur la structure si celle-ci est plate, et créera des liens symboliques pour tout ce qui peut y entrer.

Pour annuler la modification d'un paquet spécifique, il suffit d'appeler Stow avec l'option -D (qui signifie « supprimer » dans la terminologie de l'outil). Par exemple :

cd ~/dotfiles
stow -D ghostty

Cela supprime les liens symboliques que j'avais créés pour ce module sans toucher aux fichiers originaux qui sont toujours dans le dépôt. C'est une méthode très propre pour « désinstaller » des configurations d'une machine spécifique. sans les perdre complètement.

Il est crucial d'éviter une erreur très courante : N'exécutez pas Stow depuis $HOME ou depuis d'autres dossiers en dehors du dépôt.Si vous faites cela, vous risquez de créer des liens à des endroits inattendus et de vous retrouver avec un répertoire personnel encombré de fichiers indésirables. Toujours : utilisez `cd` pour accéder au dépôt, puis `stow`.

Intégrez Git et GitHub à votre flux de travail de fichiers de configuration avec Stow.

L'avantage de cette configuration est de combiner Stow et Git afin que votre Les fichiers de configuration sont versionnés, sauvegardés à distance et facilement réplicables sur d'autres machines.Le processus est très simple et ne diffère en rien de celui de n'importe quel autre projet que vous gérez avec Git.

Depuis votre dossier dotfiles, initialisez un nouveau dépôt si vous ne l'avez pas déjà fait :

cd ~/dotfiles
git init

À partir de là, vous pouvez ajouter vos fichiers, effectuer des commits et travailler avec les branches comme d'habitude. Botte il pourrait être:

git add .
git commit -m "Primer commit de mis dotfiles"

L'étape suivante consiste généralement à créer un dépôt sur GitHub, GitLab ou un autre service et à l'ajouter comme dépôt distant. Voici un exemple :

git remote add origin git@github.com:tuusuario/dotfiles.git
git push -u origin main

Gardez à l'esprit que, même si certaines personnes publient leurs fichiers de configuration dans des dépôts publics, La solution la plus prudente consiste à utiliser des référentiels privés si vous traitez des données sensibles. ou des itinéraires susceptibles de révéler trop d'informations personnelles. Dans tous les cas, vous pouvez compléter cette mesure par un chiffrement externe pour les données confidentielles si nécessaire.

Pour affiner le contrôle des versions, il est également conseillé d'avoir un fichier .gitignore dans le dépôt où vous ajoutez, par exemple, les fichiers .DS_Store ou autres fichiers que vous ne souhaitez pas télécharger. Stow ignore déjà .git par lui-même, mais Git ne connaît rien de .stow-local-ignorePar conséquent, les deux fichiers ont des objectifs différents et se complètent bien.

Le déroulement quotidien est très clair : Vous clonez votre dépôt de fichiers de configuration sur une nouvelle machine, installez Stow, exécutez « stow . » ou « stow package1 package2… » et votre environnement est répliqué.Si vous modifiez ultérieurement votre configuration Neovim ou votre fichier .zshrc, vous effectuez un commit et un push, et sur les autres machines, un simple git pull suivi d'un stow suffit pour mettre à jour les liens si vous avez ajouté de nouveaux fichiers ou paquets.