Búsqueda de sitios web

Mis consejos para mantener archivos dot en el control de código fuente


Cuando se mantiene el entorno bajo control de código fuente, las máquinas virtuales y los contenedores de desarrollo se convierten en una solución, no en un problema.

¿Alguna vez empezaste a usar una computadora nueva, por elección propia o porque la vieja dejó escapar la magia y te frustró el tiempo que tomó lograr que todo fuera perfecto ? Peor aún, ¿alguna vez has pasado algún tiempo reconfigurando el símbolo del shell y luego te has dado cuenta de que antes te gustaba más?

Para mí, este problema se agudizó cuando decidí que quería desarrollar en contenedores. Los contenedores son efímeros. Las herramientas de desarrollo son fáciles de resolver: una imagen de contenedor con las herramientas funciona. El código fuente es fácil de resolver: el control de código fuente lo mantiene y el desarrollo se realiza en ramas. Pero si cada vez que creo un contenedor necesito configurarlo cuidadosamente, será complicado.

Control de revisión en casa.

Mantener los archivos de configuración en control de versiones siempre ha sido una opción atractiva. Pero hacerlo ingenuamente resulta complicado. No es posible versionar directamente ~.

Por un lado, demasiados programas asumen que es seguro guardar secretos allí. También es la ubicación de carpetas como ~/Downloads y ~/Pictures, que probablemente no deberían tener versiones.

Mantener con cuidado un archivo .gitignore en el directorio de inicio para administrar las listas include y exclude es arriesgado. En algún momento, uno de los caminos se equivoca. Se pierden horas de configuración, archivos grandes terminan en el historial de Git o, lo peor de todo, se filtran secretos y contraseñas. Cuando esta estrategia fracasa, fracasa catastróficamente.

Mantener manualmente un mar de enlaces simbólicos tampoco funciona. El motivo del control de revisiones es evitar mantener la configuración manualmente.

Escribe un script de instalación

Esto da una idea de la primera pista sobre el mantenimiento de archivos dot en el control de código fuente. Escriba un script de instalación.

Como todos los buenos scripts de instalación, hágalo idempotent: ejecutarlo dos veces no debería agregar la configuración dos veces.

Como todos los buenos scripts de instalación, haz que sólo haga lo mínimo: utiliza cualquier otro truco para señalar los archivos de configuración en tu control de código fuente.

El directorio ~/.config

Los programas de Linux modernos buscan su configuración en ~/.config antes de buscarla directamente en el hogar. El ejemplo más importante es git, que lo busca en ~/.config/git.

Esto significa que el script de instalación puede vincular simbólicamente ~/.config a un directorio dentro de un directorio administrado controlado por fuente en el directorio de inicio:

#!/bin/bash
set -e
DOTFILES="$(dirname $(realpath $0))"
[ -L ~/.config ] || ln -s $DOTFILES/config ~/.config

Este script busca su ubicación y luego vincula ~/.config al lugar donde se realizó el check-out. Esto significa que hay pocas suposiciones sobre dónde debe estar dentro del directorio de inicio.

Archivos de abastecimiento

La mayoría de los shells todavía buscan archivos directamente en el directorio de inicio. Para resolver esto, agrega una capa de dirección indirecta. Obtener archivos de $DOTFILES significa que no es necesario volver a ejecutar el instalador al modificar la configuración del shell:

$!/bin/bash
set -e
DOTFILES="$(dirname $(realpath $0))"
grep -q 'SETTING UP BASH' ~/.bashrc || \
  echo "source $DOTFILES/starship.bash # SETTING UP BASH" >> ~/.bashrc

Nuevamente, observe que el script tiene cuidado de ser idempotente: si la línea ya está allí, no la vuelve a agregar. También es considerado con cualquier edición que ya haya realizado en .bashrc. Si bien esto no es una buena idea, no hay necesidad de castigarlo.

Prueba y vuelve a probar

Cuando se mantiene el entorno bajo control de código fuente, las máquinas virtuales y los contenedores de desarrollo se convierten en una solución, no en un problema. Pruebe un experimento: abra un nuevo entorno de desarrollo, clone sus archivos de puntos, instálelo y vea qué falla.

No lo hagas sólo una vez. Hazlo semanalmente, al menos. Esto lo hace más rápido y también le informa sobre lo que no funciona: abrir problemas, solucionarlos y repetir.

Artículos relacionados: