mise 2026.9.4 convierte la configuración de una máquina en una declaración de proyecto portable

Un gestor de versiones suele responder una pregunta concreta: ¿qué versión de Node, Python, Ruby, Go o Rust debe usar este proyecto? mise lleva tiempo respondiendo una pregunta más amplia. Puede gestionar versiones de herramientas, variables de entorno, tareas, repositorios, archivos de configuración, servicios y partes de la preparación de una estación de trabajo a partir de una configuración guardada en Git. La última versión amplía todavía más ese alcance.

La versión 2026.9.4 añade Nix como gestor de paquetes integrado para el bootstrap, permite que las declaraciones de paquetes dependan del entorno activo de mise, hace posible que las herramientas gestionadas por Packslip instalen páginas man y mejora el bloqueo de versiones y la selección de plataformas. La versión apareció el 9 de septiembre y es una de las actualizaciones recientes de mise más interesantes porque modifica la relación entre la configuración de un proyecto y la máquina anfitriona que lo ejecuta.

La diferencia importa. Un proyecto puede describir ahora una parte mayor del software que espera encontrar fuera de sus runtimes de lenguaje y, al mismo tiempo, dejar la instalación en manos del gestor nativo que ya utiliza la máquina. El resultado puede simplificar la incorporación de equipos con sistemas macOS y Linux mezclados. No es, sin embargo, un sustituto universal de Nix, de un contenedor ni de una definición completamente reproducible del sistema operativo.

Qué cambia en mise 2026.9.4

Hay cuatro cambios que conviene separar. La función principal es el nuevo backend nix: dentro de [bootstrap.packages]. Una configuración puede declarar entradas como estas:

[bootstrap.packages]
"nix:ripgrep" = "latest"
"nix:jq" = "latest"
"nix:python3Packages.pip" = "latest"

Al ejecutar mise bootstrap packages apply, esos paquetes se instalan en el perfil Nix habitual del usuario. mise no crea shims para ellos, no se apropia del store de Nix y no invoca sudo para este backend. Nix sigue siendo responsable de sus perfiles, registros, substituters, claves de confianza, cachés y modelo de rollback.

El segundo cambio es un selector env para las entradas de paquetes de bootstrap. Un paquete puede estar activo únicamente en uno o varios entornos de mise con nombre:

[bootstrap.packages]
"brew:postgresql" = { version = "latest", env = ["dev", "test"] }
"apt:clang" = { version = "latest", env = "native" }

El selector se evalúa contra el entorno activado con -E o MISE_ENV. Si una entrada también tiene un selector os, deben cumplirse ambas condiciones. Una persona que trabaje en el entorno dev puede recibir PostgreSQL, mientras que un entorno de documentación o parecido a producción no lo activa. La declaración permanece en la configuración aunque el entorno esté inactivo, y mise la protege frente a la poda.

El tercer cambio afecta a Packslip, la vía de mise para distribuir artefactos de lanzamiento firmados de las herramientas. Las versiones instaladas con Packslip ahora pueden incluir recursos estáticos de páginas man, además de completados de shell y capacidades para agentes. Cuando una herramienta de ese tipo está activa, mise añade la raíz de sus páginas man a MANPATH y conserva las rutas definidas por el sistema y por quien invoca el proceso. Las instalaciones existentes deben reinstalarse antes de que aparezcan las páginas man recién declaradas.

El cuarto cambio es menor, pero práctico, para el ejecutor de tareas. task.quiet, o la variable de entorno MISE_TASK_QUIET, oculta los prefijos propios de mise, los mensajes de estado y las cabeceras que repiten los comandos, sin esconder la salida producida por la tarea. El modo anterior output = "quiet" está obsoleto y tiene prevista su eliminación en 2027.9.3.

También hay un grupo importante de correcciones de precisión. Incluye herramientas perezosas con dependencias perezosas, resolución de arquitecturas ARM, selección de artefactos cuando no existe un binario nativo, firma de archivos Mach-O enlazados físicamente por Homebrew, nombres de shims en Windows, compatibilidad con glibc y archivos de bloqueo sensibles a la plataforma. La versión mejora además la indexación del historial de dotfiles: reconstruye los metadatos dentro del proceso en vez de lanzar Git para cada checkpoint. La persona mantenedora informa de que un caso de prueba con 80 checkpoints y 44 archivos pasó de unos 26–28 segundos a menos de un segundo.

La idea útil no es «Nix a través de mise»

Sería fácil describir la versión como una integración con Nix y terminar ahí. Esa lectura deja fuera la decisión de diseño más útil. mise intenta ofrecer una superficie declarativa común para varias clases de dependencias sin fingir que todas tienen la misma semántica.

Un runtime de lenguaje encaja naturalmente en la definición de herramientas de un proyecto. Una biblioteca de compilación, una cabecera del sistema, una utilidad de línea de comandos o un servidor de base de datos suelen pertenecer al gestor de paquetes del sistema anfitrión. Un paquete de Nix pertenece a un perfil de Nix o a una configuración de NixOS. Antes de 2026.9.4, un equipo que quería describir todas esas capas dentro de un mismo flujo de bootstrap tenía que escribir instrucciones separadas o reunir scripts específicos para cada gestor. El nuevo backend ofrece una declaración común para el proyecto, pero mantiene la propiedad real en manos de Nix.

La separación se ve en los comandos. mise bootstrap packages use registra una declaración. mise bootstrap packages apply instala los elementos que faltan. mise bootstrap packages status informa de qué está presente, qué falta, qué no está disponible y qué se ha omitido. mise bootstrap packages upgrade es la operación explícita de actualización. Aplicar una declaración cuyo valor es latest no necesariamente actualiza un paquete ya instalado desde una fuente móvil. Es una distinción sensata: la incorporación inicial debería converger hacia el estado ausente, no actualizar silenciosamente una estación de trabajo cada vez que alguien entra en un repositorio.

El backend de Nix también ofrece una ruta de exportación para NixOS. Un equipo puede registrar declaraciones sin instalarlas:

mise bootstrap packages use --no-install nix:ripgrep nix:jq
mise bootstrap packages export --format nix > packages.nix

El módulo generado puede importarse después desde una configuración de NixOS. En ese flujo, NixOS es responsable de la evaluación, la selección de paquetes, los overlays, la activación del sistema y el rollback. mise funciona como una capa cómoda para autoría y traducción, no como un segundo administrador del sistema.

Ese límite es importante. Si un proyecto usa mise bootstrap packages apply para una declaración nix:, el paquete termina en el perfil del usuario. Si la misma intención debe formar parte de la configuración del sistema NixOS, el flujo más prudente es usar --no-install, exportar el módulo, revisarlo y reconstruir mediante el proceso de NixOS ya existente. Las dos rutas están relacionadas, pero no son intercambiables.

Los selectores de entorno resuelven un problema real de los equipos

Es probable que el selector env importe más a los equipos corrientes que el backend de Nix. Muchos repositorios tienen varios modos de operación, pero solo un documento de preparación. Un proyecto frontend puede necesitar Node y las herramientas del navegador en todos los entornos, PostgreSQL para las pruebas de integración y una biblioteca de procesamiento de imágenes únicamente para una compilación nativa. Un monorepo puede tener un entorno predeterminado pequeño para editar, un entorno test con bases de datos y navegadores, y un entorno release con utilidades de firma.

Sin selectores, el archivo de preparación suele elegir entre dos opciones poco satisfactorias. Puede instalar todas las dependencias posibles en cada máquina, lo que vuelve lento y ruidoso el entorno predeterminado, o puede dividir la preparación en scripts que se desincronizan a medida que cambian las plataformas y los equipos. Las declaraciones condicionales hacen visible la intención en un único lugar.

La función es deliberadamente más estrecha que una lógica de configuración arbitraria. Un paquete puede seleccionarse por sistema operativo o por entorno de mise; no es un lenguaje de programación general para instalar paquetes. Las condiciones os y env se combinan, no se tratan como alternativas. Un paquete exclusivo de macOS dentro del entorno native seguirá inactivo en Linux aunque coincida el nombre del entorno.

Esa previsibilidad ayuda durante la revisión. Una persona revisora puede ver que un paquete está restringido a macos, linux/x64, dev o test sin tener que evaluar un script de shell opaco. También hace más útil la salida de estado. Que el gestor de paquetes no esté disponible en el host actual no debería interpretarse automáticamente como una prueba de que el proyecto está correctamente preparado; la documentación advierte que las declaraciones omitidas requieren una inspección independiente.

Hay un detalle sutil en el ciclo de vida. Los paquetes de un entorno inactivo siguen declarados y están protegidos frente a la poda. Es el valor predeterminado más seguro, porque cambiar temporalmente a un entorno pequeño no debería hacer que otro entorno pierda sus herramientas. También significa que quien espere que el cambio de entorno recupere espacio en disco necesitará una estrategia de limpieza explícita y específica para cada gestor. La presencia declarativa y la reducción del uso local de disco son objetivos distintos.

Las páginas man hacen que las herramientas gestionadas parezcan menos binarios descargados

Los gestores de herramientas suelen concentrarse en poner ejecutables en PATH. Eso basta para lanzar un comando rápidamente, pero encaja mal con utilidades maduras cuya documentación, ejemplos y detalles operativos viven en páginas man. El nuevo soporte de recursos de Packslip permite que una herramienta empaquetada distribuya esas páginas como parte de su versión gestionada.

La implementación tiene un alcance intencionadamente limitado. mise añade las raíces man para las versiones respaldadas por Packslip y conserva el MANPATH original de quien invoca el proceso como parte de la identidad de la caché de entorno. Así evita reutilizar un proceso almacenado que fue construido para una ruta de documentación distinta. Quien actualice a 2026.9.4 no debería asumir que todas las instalaciones existentes incorporan las páginas automáticamente; hay que reinstalar la herramienta correspondiente.

Es un cambio pequeño con un efecto útil en la incorporación. Un repositorio puede fijar una herramienta y hacer que tool --help y man tool apunten a la misma versión gestionada. Resulta especialmente práctico para herramientas de infraestructura de línea de comandos cuyo comportamiento cambia de forma significativa entre versiones. La función no convierte cualquier binario arbitrario en un componente completamente empaquetado del sistema operativo, y las convenciones de páginas man siguen variando entre plataformas.

Los arreglos de bloqueos y artefactos merecen atención

Las correcciones de empaquetado son menos visibles que el soporte de Nix, pero más relevantes para CI. Ahora mise lock --platform verifica manifiestos de lanzamiento firmados y registra la URL, la suma de comprobación, el tamaño y la persona o entidad firmante de cada destino solicitado. Esto importa cuando un archivo de bloqueo se crea en una máquina y se consume en otra. Un bloqueo que solo identifica una versión, pero no el artefacto exacto, deja demasiado margen para que la resolución específica de la plataforma cambie sin aviso.

La selección de artefactos también evita recurrir a un source.tar.gz genérico cuando el registro no tiene un binario publicado para el host. Es un fallo más claro que descargar código fuente como si fuera una versión ejecutable. En Linux con glibc, el selector considera ahora el requisito mínimo de glibc de un artefacto y puede elegir una compilación estática musl compatible cuando existe. Esto no garantiza la compatibilidad: las bibliotecas nativas, las funciones del kernel, las instrucciones de la CPU y las suposiciones del runtime también pueden importar. Simplemente hace visible para el resolvedor una incompatibilidad frecuente.

La corrección de Windows es igualmente concreta. Los enlaces de Packslip usan ahora el nombre correcto con extensión .exe en Windows, mientras que los sistemas Unix conservan nombres de shim sin extensión. La corrección de Homebrew resuelve un fallo más inesperado: los ejecutables Mach-O enlazados físicamente podían instalarse correctamente, pero macOS podía eliminarlos después porque la firma no cubría todos los alias. Son defectos que rara vez aparecen en el anuncio de una función, aunque determinan si un gestor de versiones merece confianza en una flota heterogénea.

Una primera prueba con cuidado

La forma adecuada de evaluar esta versión es empezar con un repositorio desechable y una ejecución simulada. La documentación oficial del bootstrap recomienda revisar la configuración y ejecutar mise bootstrap --dry-run antes de aplicarla. El mismo hábito sirve para las operaciones específicas de paquetes. Un experimento mínimo podría declarar una herramienta, un paquete de Nix y un paquete del host restringido por entorno.

[tools]
node = "22"

[env]
_.python.venv = { path = ".venv", create = true }

[bootstrap.packages]
"nix:jq" = "latest"
"brew:postgresql" = { version = "latest", os = "macos", env = ["test"] }
"apt:postgresql" = { version = "latest", os = "linux", env = ["test"] }

Revisa la salida del entorno predeterminado y después la del entorno de pruebas. Confirma que los comandos del gestor de paquetes son los esperados, que el paquete del host no se activa en el sistema operativo equivocado y que la declaración de Nix se resuelve mediante el registro que pretendes usar. En un proyecto guardado en Git, la configuración debe revisarse como código. Puede instalar paquetes, cambiar la activación del shell, crear servicios, escribir archivos y ejecutar hooks.

Una secuencia razonable es:

mise trust
mise bootstrap packages status
mise bootstrap --dry-run
mise -E test bootstrap --dry-run
mise bootstrap packages apply --dry-run

Solo después de entender la salida debería aplicarse la configuración. En CI está disponible mise bootstrap --yes para la operación desatendida, pero la opción no interactiva elimina un paso de confirmación; no vuelve segura una configuración que no merece confianza. Fija versiones o revisiones de origen cuando importe la repetibilidad y mantén bajo revisión los archivos de bloqueo de CI.

Para Nix en particular, la documentación oficial exige Nix 2.24 o posterior, con nix-command y flakes activados, además de soporte moderno para nix profile. La abreviatura nix:ripgrep se resuelve mediante el registro nixpkgs de la máquina. El valor latest significa lo que esa fuente proporcione en ese momento; no es un bloqueo. Si la compilación debe poder recuperarse más adelante, usa una fuente fijada a una revisión o una entrada de registro fijada. Este backend no admite una fijación de versión de paquete como nix:ripgrep@14.

La documentación también recalca que mise no inicializa ni migra un perfil Nix antiguo. Si la máquina informa de un formato de perfil heredado de nix-env, ese es un problema de administración de Nix que debe resolverse por separado. La herramienta no lo elimina ni lo convierte en silencio, una propiedad de seguridad adecuada que puede sorprender a quien espere una migración de un solo comando.

Lo que no sustituye

mise 2026.9.4 encaja bien cuando el problema es coordinar herramientas existentes. Resulta menos convincente cuando el requisito central es una compilación hermética o un sistema inmutable. Un flake de Nix puede fijar entradas y describir un shell de desarrollo con un control más profundo del grafo de dependencias y de la evaluación. devenv construye una capa orientada al desarrollo sobre Nix, con servicios, tareas, soporte de lenguajes y archivos de bloqueo. Un contenedor o un devcontainer puede proporcionar un límite más fuerte para CI y para la incorporación de nuevas personas.

La comparación con asdf también es útil. asdf es principalmente un gestor de versiones de múltiples runtimes, con un sistema de plugins y un archivo .tool-versions por proyecto. Es una opción más sencilla para equipos que necesitan runtimes consistentes y cambio automático, pero no quieren un modelo más amplio de preparación de la máquina. direnv cubre otra parte del problema: cargar cambios de entorno al entrar en un directorio. Puede combinarse con mise, Nix u otros productores de entornos.

La elección debería seguir al problema, no al número de integraciones disponibles. Usa mise cuando un repositorio se beneficie de una configuración única para runtimes, tareas, variables de entorno y una preparación del host cuidadosamente delimitada. Usa Nix nativo cuando la reproducibilidad y el control del grafo de paquetes sean los requisitos principales. Usa devenv cuando el equipo quiera un entorno de desarrollo basado en Nix con configuración de servicios y flujos de trabajo de más alto nivel. Usa asdf cuando baste con gestionar versiones de runtimes. Usa direnv cuando la pieza que falta sea la activación automática del entorno. Las herramientas pueden coexistir, pero la propiedad solapada de PATH, las versiones de lenguaje y los hooks del shell produce fallos difíciles de interpretar.

Límites de seguridad y confianza

La versión es de código abierto y el repositorio cuenta con licencia MIT y una política de seguridad publicada. La etiqueta de lanzamiento firmada y la verificación de manifiestos de Packslip son señales útiles para la cadena de suministro, pero ninguna elimina los riesgos de ejecutar la configuración. Un binario de mise firmado puede aplicar fielmente un mise.toml malicioso; verificar la firma demuestra de dónde procede un artefacto, no que el paquete, hook, servicio o cambio de archivos solicitado por un repositorio sea apropiado para tu máquina.

El bootstrap puede realizar acciones destructivas. El comando puede instalar paquetes, modificar archivos de activación, gestionar servicios, actualizar repositorios, escribir dotfiles y ejecutar tareas. Por eso importan los pasos de simulación y confianza. No confíes automáticamente en un repositorio solo porque sea público o porque su configuración sea breve. Lee los hooks, inspecciona las URL remotas, comprueba los nombres de los paquetes y presta atención a los comandos que usan privilegios elevados o modifican el inicio del shell.

Nix introduce sus propias decisiones de confianza. Los registros, cachés binarios, substituters, claves públicas de confianza y entradas de flakes afectan a lo que se descarga y se compila. La integración de mise utiliza la configuración existente de Nix en lugar de crear un modelo de confianza separado. Es cómodo, pero implica que la revisión de seguridad no puede detenerse en el archivo de mise. Los equipos deberían documentar qué registros y cachés de Nix aceptan y cómo fijan las revisiones de origen.

El desarrollo activo del proyecto es otra razón para adoptar la versión por etapas. Una versión con muchos cambios multiplataforma puede corregir fallos reales y, al mismo tiempo, exponer casos límite en shells, gestores de paquetes o arquitecturas que la persona mantenedora no pudo probar localmente. Empieza con una máquina de desarrollo, continúa con un runner de CI limpio y después amplía el despliegue. Conserva la ruta de preparación anterior hasta que el nuevo flujo de bootstrap haya demostrado que puede eliminarse y recrearse de manera predecible.

Quién debería probarlo ahora

Los mejores candidatos son los equipos que ya usan mise y han acumulado scripts separados de incorporación para Homebrew, apt, Nix, dotfiles o servicios de prueba. Son quienes más pueden ganar con los selectores de entorno y con la distinción entre «declarado» e «instalado». Los repositorios con macOS y Linux mezclados también encajan bien, sobre todo cuando las personas necesitan los mismos nombres de tareas del proyecto, pero gestores de paquetes nativos distintos.

También merece la pena probarlo en proyectos con mucho uso de herramientas de línea de comandos. Las páginas man de Packslip, los manifiestos firmados, los bloqueos sensibles a la plataforma y la mejor selección de artefactos atienden detalles que afectan al uso diario, no solo a una demostración. Un proyecto que distribuye sus propias herramientas puede comprobar si las versiones gestionadas se comportan ahora de forma coherente entre shells y plataformas.

El público menos adecuado es el equipo que busca una mutación automática e invisible de la máquina. mise hace que la preparación sea más legible, pero no la vuelve inocua. Tampoco debe confundirse una declaración latest con reproducibilidad. El nuevo backend de Nix es un puente entre una declaración a nivel de proyecto y el gestor de paquetes nativo, no una abstracción mágica que borre la semántica de cada gestor.

Veredicto

La parte más importante de mise 2026.9.4 es la forma en que vuelve condicionales y revisables las dependencias del host. El soporte de Nix resulta valioso porque respeta el modelo de propiedad de Nix, mientras que los selectores env resuelven un problema práctico en repositorios con más de un modo de trabajo. Las mejoras de páginas man y bloqueos refuerzan las partes menos vistosas de la gestión de herramientas, y las correcciones multiplataforma hacen que la versión sea relevante para CI, no solo para shells locales.

Pruébala si tu flujo actual ya se parece a una colección de archivos de runtimes, scripts de paquetes, definiciones de tareas e instrucciones específicas por entorno. Empieza con una configuración pequeña, usa simulaciones, fija lo que deba ser repetible y conserva como autoridad las definiciones de Nix a nivel de sistema o de contenedor allí donde sean necesarias. Para un gestor de runtimes sencillo, mise puede aportar más maquinaria de la necesaria. Para un equipo que intenta hacer comprensible toda la preparación del desarrollo sin fingir que todos los sistemas operativos son iguales, esta versión es una actualización razonable que merece una prueba.

Fuentes

La adaptación se basa en la información de la versión 2026.9.4 de mise, la documentación de bootstrap y paquetes de Nix, el repositorio y la política de seguridad del proyecto, además de la documentación de asdf, direnv y devenv mencionada en el artículo.