Por Eric Driussi
⚠️️ Ojo este post no es Windows-friendly! No tengo mucho contexto de que tanto de esto es aplicable a Windows ⚠️️
~/dotfiles/
tomando este repo como referencia para la estructura de directorios.~/dotfiles/
.stow
desde ~/dotfiles/
.Si queremos configurar nuestras aplicaciones, probablemente queremos también tener cierta seguridad de que el tiempo invertido en hacerlo no es en vano.
Es común querer tener un backup de estas configuraciones que viva separado de nuestros backups de ficheros y datos personales (incluso en repositorios remotos).
Tal vez querramos compartir estas configuraciones, ya sea con amigos y compañeros o con anónimos en Internet.
Como ejemplo personal, cuando me conecto por SSH un VPS, espero que mis aplicaciones de terminal y mi shell se comporten como en mi sistema local.
Si usamos ordenadores distintos con cierta frecuencia, resulta cómodo poder tener nuestro entorno configurado de la misma manera en todos ellos.
Incluso si usamos instalaciones distintas en la misma máquina, puede ser interesante que esa sincronización no esté acoplada a una partición, por motivos de seguridad.
Al fin y al cabo lo que queremos compartir son las configuraciones, no los datos (menos que menos si son sensibles).
Esto no es fácil de mantener de forma sostenible, algo tan simple como mantener un versionado de estos ficheros puede ser un auténtico dolor de cabeza.
Usando stow
y git
podemos manejar esta situación de manera muy simple, aunque el setup requiere algo de trabajo.
Por dotfiles entendemos esos ficheros ocultos que empiezan por .
y a menudo encontramos tirados por la /home/
de los sistemas *nix. Realmente, no tienen porqué ser ocultos ni comenzar por .
, pero de ahí el nombre.
Son ficheros que muchas aplicaciones (aunque por desgracia no todas), nos ofrecen para portabilizar su configuración.
Las más educadas leen estas configuraciones en ~/.config/app/conf
, las menos esperan encontrar los ficheros directamente en ~/
.
La idea es que te llevas tu conf
contigo, y la aplicación se comporta de la misma forma en cualquier sistema.
Los enlaces simbólicos nos sirven para hacer creer al SO que hay un fichero donde realmente no lo hay.
Es una referencia a un fichero que puede estar donde nosotros queramos.
Puedes crear uno desde la terminal con ln -s ~/un_fichero.sh ~/carpeta/
.
Esto creará una referencia a un_fichero.sh
en carpeta/
y cualquier cambio que hagamos al fichero original llegará también a la referencia.
Dicho mal y pronto, stow
es un gestor de symlinks.
Dado un directorio, crea un sistema de symlinks análogo.
Suele venir pre-instalado en la mayoría de los sistemas *nix.
Stow is a symlink farm manager which takes distinct sets of software and/or data
located in separate directories on the filesystem, and makes them all appear to be
installed in a single directory tree.
En su origen hacía las veces de un gestor de paquetes, sin embargo, podemos sacarle más provecho:
However Stow is still used not only for software package management, but also for
other purposes, such as facilitating a more controlled approach to management of
configuration files in the user’s home directory, especially when coupled with version
control systems.
Supón que nuestro editor de texto favorito espera un fichero vimrc
bajo .config/nvim/
.
Si lanzamos stow
desde un directorio análogo, se encargará de crear el enlace simbólico correspondiente:
~
├──dotfiles [YOU_ARE_HERE]
│ ├── nvim
│ │ ├── .config
│ │ ├── nvim
│ │ │ ├── vimrc
...
Si lanzamos stow nvim
desde dotfiles
, veremos que se nos ha creado la siguiente estructura, directorios incluidos (suponiendo que no hubiera ya un vimrc
en .config/nvim/
):
~
├── .config
├── nvim
│ ├── vimrc
...
Esto solamente hace referencia a nuestro fichero de configuración.
Por defecto, stow
clonará la estructura de directorios desde el cwd
(esto es configurable mediante el flag --dir
), hacia el directorio superior al que se encuentra (esto es configurable mediante el flag --target
).
Por este motivo, los ejemplos suponen que tu directorio de dotfiles está en ~/dotfiles/
. Mi consejo es que te adieras a este comportamiento, ¡te ahorrarás sorpresas!
Podemos tener todos nuestros ficheros de configuración centralizados en un repo tal que así y desplegarlos con stow *
.
Este despliegue solo será necesario una vez, puesto que al editar los ficheros en la carpeta de dotfiles, se actualizarán los symlinks automáticamente.
Como se menciona arriba, hay programas que esperan ficheros en ~/
. Aquí hay un ejemplo de cómo gestionar esos casos.
Otros esperan sus ficheros directamente bajo .config
. No hay problema: como en el resto de los casos, creamos una estructura análoga y stow
se hace cargo.
Esto, además de ser tremedamente cómodo para mantener el orden, nos permite tener un versionado eficiente de estos ficheros.
Además, facilita mucho la automatización del proceso de instalación de un SO.
Es probable que si intentas usar stow
en un sistema ya bastante configurado, éste se niegue a colaborar.
Esto se debe a que si detecta que hay ficheros donde va a establecer el symlink, te avisará y no hará nada.
Tiene flags que te permiten machacar todo lo que haya directamente, pero mi consejo es que te tomes tu tiempo al principio y asegures bien dónde está cada cosa.
Lo menos arriesgado es ir migrando las configuraciones de una en una, moviendo el fichero (o directorio) a tu carpeta de dotfiles, asegurando que la estructura es la correcta, eliminando la configuración vieja y lanzando finalmente el comando con una config fresca.
Por algún motivo, MacOS no parece llevarse muy bien con los symlinks.
Los programas que uso en Mac pierden su capacidad de hacer hot-reload al usar symlinks. Cada vez que actualizo la configuración de yabai
por ejemplo, tengo que lanzar brew services restart yabai
para que pille el cambio.
Esto ocurre solo al usar symlinks y solo en MacOS, no entiendo del todo el porqué.
¯\_ (ツ)_/¯
¿Quieres más? te invitamos a suscribirte a nuestro boletín para avisarte cada vez que recopilemos contenido de calidad que compartir.
Si disfrutas leyendo nuestro blog, ¿imaginas lo divertido que sería trabajar con nosotros? ¿te gustaría?
Pero espera 🖐 que tenemos un conflicto interno. A nosotros las newsletter nos parecen 💩👎👹 Por eso hemos creado la LEAN LISTA, la primera lista zen, disfrutona y que suena a rock y reggaeton del sector de la programación. Todos hemos recibido newsletters por encima de nuestras posibilidades 😅 por eso este es el compromiso de la Lean Lista