Un framework en Python sobre Pydantic para dejar de duplicar configs por entorno
Un desarrollador publica una biblioteca que convierte los ficheros .env en clases con herencia, apoyándose en Pydantic para validar los tipos. El autor la ha reescrito después como bakefile.

Configurar varios entornos en Python suele acabar en una colección de ficheros .env que se repiten y se contradicen. Un desarrollador ha publicado un framework que ataca ese problema tratando la configuración como clases con herencia múltiple en lugar de pares clave-valor. Se apoya en BaseModel de Pydantic para la validación de tipos y en mixins para componer cada entorno y cada servicio. El autor lo ha reestructurado después y lo ha publicado como biblioteca bajo el nombre bakefile, un ejecutor de tareas con la misma herencia de base, servicio e instancia.
El diagnóstico es el de siempre. Cada entorno (sit, uat, canary, prod, o los nombres que use cada equipo) tiene su juego de ficheros, y cada servicio (Cloud Run, Dataflow y compañía) duplica buena parte de los valores compartidos: URL del registro de Docker, credenciales de GCP, subredes. Como los pipelines de CI/CD reflejan esa separación, también se duplican. Un cambio que toca tres entornos son tres ediciones, tres comprobaciones del script de despliegue y tres oportunidades de equivocarse.
Tres capas y un mixin por caso
La capa base (BaseConfigs) guarda lo global: el identificador de entorno, un booleano de desarrollo local, el nivel de log por módulo y la ruta a las credenciales de GCP. Además define métodos plantilla como setup_environment(), deploy() y assert_deploy().
Encima van los mixins de servicio, por ejemplo DataflowConfigsMixin, con variables como dataflow_job_name, dataflow_gcp_project o dataflow_subnetwork, y su propia lógica de despliegue y validación. La última capa es la de instancia, un mixin por job concreto que fija el nombre y ajusta la comprobación posterior, sea consultar BigQuery o llamar a una API.
La composición se resuelve con herencia múltiple: una clase de producción encadena el mixin de instancia, el de entorno, el de servicio y la base. get_configs() devuelve el objeto que corresponde según una única variable ENV.
El framework trae un CLI, ac, con tres comandos. ac echo_configs imprime las variables resueltas para el entorno activo en formato export, de modo que basta un eval $(ac echo_configs) dentro del pipeline para generarlas en tiempo de ejecución. ac deploy dispara el método de despliegue del objeto de configuración y ac assert_deploy ejecuta sus validaciones.
Como todos los objetos implementan la misma interfaz, el mismo YAML sirve para sit, uat y prod: solo cambia ENV. Es la parte que más se nota al operarlo, porque elimina la lógica de CI/CD específica por servicio.
Conviene ponerle peros. El autor no indica licencia ni enlaza un repositorio, y las cifras de uso no existen: es el framework de una persona, no un proyecto con comunidad detrás. La idea, en cambio, es trasladable a cualquier stack: que la configuración tenga la misma jerarquía que la infraestructura que describe. Queda por ver si bakefile acaba publicando licencia y paquete instalable, que es lo que hace falta para meterlo en un pipeline ajeno.
