mise 2026.9.4 превращает настройку машины в переносимое описание проекта

Обычно менеджер версий отвечает на узкий вопрос: какую версию Node, Python, Ruby, Go или Rust должен использовать проект? mise уже некоторое время отвечает на более широкий. Он умеет управлять версиями инструментов, переменными окружения, задачами, репозиториями, dotfiles, сервисами и частью настройки рабочей станции через конфигурацию, хранящуюся в Git. Последний релиз ещё сильнее расширяет эту границу.

В версии 2026.9.4 Nix стал встроенным пакетным менеджером для начальной настройки, объявления пакетов получили зависимость от активного окружения mise, инструменты, установленные через Packslip, могут включать man-страницы, а блокировки и выбор платформы стали надёжнее. Релиз вышел 9 сентября и интересен прежде всего тем, что меняет связь между конфигурацией проекта и окружающей его машиной.

Разница существенна. Теперь проект может описать большую часть программного обеспечения, которое ожидает найти за пределами языковых рантаймов, и при этом передать установку тому нативному менеджеру, который уже используется на конкретной машине. Для команд с macOS и Linux это способ сделать подключение нового разработчика аккуратнее. Но универсальной заменой Nix, контейнеру или полностью воспроизводимому описанию операционной системы mise не становится.

Что изменилось в mise 2026.9.4

В релизе есть четыре изменения, которые стоит рассматривать отдельно. Главное — новый бэкенд nix: в секции [bootstrap.packages]. Конфигурация может содержать такие записи:

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

Команда mise bootstrap packages apply установит эти пакеты в обычный пользовательский профиль Nix. mise не создаёт для них шимы, не получает контроль над хранилищем Nix и не вызывает sudo для этого бэкенда. Профили, реестры, substituter-ы, доверенные ключи, кэши и модель отката остаются зоной ответственности Nix.

Второе изменение — селектор env для записей начальных пакетов. Пакет может быть активен только в одном или нескольких именованных окружениях mise:

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

Селектор проверяется относительно окружения, активированного через -E или MISE_ENV. Если у записи есть ещё и селектор os, совпасть должны оба условия. Разработчик в окружении dev получит PostgreSQL, тогда как более лёгкое окружение для документации или имитации production не будет его активировать. Объявление остаётся в конфигурации, даже когда окружение неактивно, и mise защищает его от удаления при очистке.

Третье изменение относится к Packslip — подписанному пути установки релизных артефактов для инструментов в mise. Версии, установленные через Packslip, теперь могут включать статические ресурсы с man-страницами наряду с shell-дополнениями и навыками для агентов. Когда такой инструмент активен, mise добавляет корень его man-страниц в MANPATH, сохраняя системные пути и пути, заданные вызывающим процессом. Уже установленные версии нужно переустановить, прежде чем в них появятся новые страницы.

Четвёртое изменение меньше по масштабу, но удобно в ежедневной работе. task.quiet или переменная окружения MISE_TASK_QUIET скрывает собственные префиксы задач, сообщения о состоянии и заголовки с эхо-командами, не скрывая вывод самой задачи. Старый режим output = "quiet" объявлен устаревшим и должен исчезнуть в 2027.9.3.

Кроме того, в релиз вошла заметная группа исправлений корректности. Они касаются ленивых инструментов с ленивыми зависимостями, разрешения ARM-архитектур, выбора релизных артефактов при отсутствии нативного бинарника, подписи жёстко связанных Mach-O-файлов в Homebrew, имён шимов Windows, совместимости с glibc и платформозависимых lock-файлов. Индексация истории dotfiles также стала быстрее: метаданные теперь восстанавливаются внутри процесса, вместо запуска Git для каждой контрольной точки. По сообщению сопровождающего, тест со 80 контрольными точками и 44 файлами сократился примерно с 26–28 секунд до менее чем одной секунды.

Полезная идея — не просто «Nix через mise»

Релиз легко описать как интеграцию с Nix и на этом остановиться. Но важнее другое проектное решение. mise пытается дать единую декларативную поверхность для нескольких типов зависимостей, не делая вид, будто их семантика одинакова.

Языковой рантайм естественно описывать в настройках инструментов проекта. Библиотека компилятора, системный заголовок, консольная утилита или сервер базы данных чаще относятся к пакетному менеджеру хоста. Пакет Nix принадлежит профилю Nix или конфигурации NixOS. До версии 2026.9.4 команде, которая хотела описать все эти слои одним процессом начальной настройки, приходилось писать отдельные инструкции или собирать набор скриптов для разных менеджеров. Новый бэкенд создаёт общее объявление, но оставляет фактическое владение Nix.

Разделение видно по командам. mise bootstrap packages use записывает объявление. mise bootstrap packages apply устанавливает отсутствующие элементы. mise bootstrap packages status показывает, что уже есть, чего не хватает, что недоступно или пропущено. mise bootstrap packages upgrade — явная операция обновления. Применение объявления со значением latest не обязательно обновляет уже установленный пакет из движущегося источника. Это разумно: подключение проекта должно доводить отсутствующее состояние до нужного, а не незаметно обновлять рабочую станцию каждый раз при входе в репозиторий.

У Nix-бэкенда есть и путь экспорта в NixOS. Команда может записать объявления, не устанавливая их:

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

Полученный модуль затем можно импортировать в конфигурацию NixOS. В таком сценарии NixOS отвечает за вычисление конфигурации, выбор пакетов, overlays, активацию системы и откат. mise выступает удобным слоем подготовки и преобразования, а не вторым системным менеджером.

Это важная граница. Если проект применяет mise bootstrap packages apply к объявлению nix:, пакет попадает в пользовательский профиль. Если ту же идею нужно сделать частью системной конфигурации NixOS, безопаснее использовать --no-install, экспортировать модуль, проверить его и выполнить пересборку через уже существующий процесс NixOS. Эти пути связаны, но не взаимозаменяемы.

Селекторы окружений решают практическую командную задачу

Селектор env, вероятно, окажется важнее для обычных команд, чем сам бэкенд Nix. Во многих репозиториях есть несколько режимов работы, но только один документ по настройке. Фронтенд-проекту могут требоваться Node и браузерный toolchain в любом окружении, PostgreSQL — для интеграционных тестов, а библиотека обработки изображений — только для нативной сборки. В монорепозитории может быть небольшое окружение по умолчанию для редактирования, окружение test с базами и браузерами и окружение release с утилитами подписи.

Без селекторов файл настройки обычно выбирает один из двух неудобных вариантов. Можно установить все возможные зависимости на каждой машине, сделав обычное окружение медленным и перегруженным, либо разделить настройку на скрипты, которые начнут расходиться по мере изменения платформ и команд. Условные объявления позволяют хранить намерение в одном месте.

Возможность намеренно уже произвольной логики конфигурации. Пакет можно выбирать по операционной системе или окружению mise; это не универсальный язык программирования для установки пакетов. Условия os и env объединяются, а не считаются альтернативами. Пакет только для macOS в окружении native останется неактивным на Linux, даже если имя окружения совпадает.

Предсказуемость помогает при ревью. Проверяющий видит, что пакет ограничен macos, linux/x64, dev или test, и ему не нужно вычислять непрозрачный shell-скрипт. Осмысленнее становится и вывод статуса. Недоступный на текущем хосте пакетный менеджер не следует автоматически трактовать как доказательство того, что проект полностью подготовлен; документация предупреждает, что пропущенные объявления нужно проверять отдельно.

Есть тонкость жизненного цикла. Пакеты неактивного окружения остаются объявленными и защищёнными от очистки. Это безопасное значение по умолчанию: временный переход к меньшему окружению не должен лишать пользователя инструментов, нужных в другом режиме. Но тот, кто рассчитывает освобождать диск одним переключением окружения, должен отдельно продумать очистку в рамках конкретного менеджера. Декларативное наличие и минимизация локального диска — разные задачи.

Man-страницы делают управляемые инструменты полноценнее

Менеджеры инструментов обычно сосредоточены на том, чтобы положить исполняемые файлы в PATH. Для быстрой команды этого достаточно, но зрелые утилиты часто хранят документацию, примеры и эксплуатационные детали именно в man-страницах. Новая поддержка ресурсов Packslip позволяет поставляемому инструменту включать эти страницы в состав управляемой версии.

Реализация намеренно ограничена. mise добавляет корни man-страниц для версий инструментов, полученных через Packslip, и учитывает исходный MANPATH вызывающего процесса при формировании идентичности кэша окружения. Благодаря этому не переиспользуется кэшированный процесс, созданный для другого пути документации. Пользователю, обновившемуся до 2026.9.4, не стоит ожидать, что страницы появятся во всех прежних установках автоматически: соответствующий инструмент нужно переустановить.

Изменение небольшое, но полезное для подключения к проекту. Репозиторий может закрепить инструмент так, чтобы tool --help и man tool относились к одной и той же управляемой версии. Особенно это удобно для консольных инфраструктурных инструментов, поведение которых заметно меняется между релизами. Возможность не превращает любой произвольный бинарник в полноценный компонент операционной системы, а соглашения о системных man-страницах по-прежнему различаются между платформами.

Исправления блокировок и артефактов заслуживают внимания

Исправления упаковки менее заметны, чем поддержка Nix, но для CI могут быть важнее. Теперь mise lock --platform проверяет подписанные манифесты релизов и записывает для каждой запрошенной цели URL, контрольную сумму, размер и подписанта. Это имеет значение, когда lock-файл создают на одной машине, а используют на другой. Файл, содержащий только версию, но не точный артефакт, оставляет слишком много места для того, чтобы платформенное разрешение изменилось незаметно.

Выбор артефакта также больше не сваливается на общий source.tar.gz, если в реестре нет опубликованного бинарника для хоста. Это лучше, чем скачать исходный код так, будто он является готовым релизом. На Linux с glibc селектор теперь учитывает минимальное требование к версии glibc и способен выбрать совместимую статическую сборку musl, если она существует. Совместимость это не гарантирует: всё ещё важны нативные библиотеки, возможности ядра, инструкции процессора и предположения рантайма. Исправление лишь делает одну распространённую несовместимость видимой для разрешателя.

Исправление для Windows столь же конкретно. Ссылки Packslip теперь используют правильное имя с расширением .exe, тогда как Unix сохраняет имена шимов без расширения. Исправление Homebrew связано с более неожиданной проблемой: жёстко связанные исполняемые Mach-O-файлы могли успешно установиться, но позднее macOS завершала их после того, как подпись не охватывала каждый псевдоним. Именно такие дефекты редко попадают в заголовок новости о функции, но определяют, можно ли доверять менеджеру версий в смешанном парке машин.

Как провести первый тест

Оценивать этот релиз лучше всего в отдельном временном репозитории, начав с пробного запуска. В официальной документации по bootstrap рекомендуется проверить конфигурацию и выполнить mise bootstrap --dry-run до применения. Такой же подход подходит для отдельных операций с пакетами. Минимальный эксперимент может объявить один инструмент, один пакет Nix и один пакет хоста с ограничением по окружению.

[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"] }

Проверьте вывод для окружения по умолчанию, а затем для test. Убедитесь, что вызываются именно те менеджеры пакетов, которых вы ожидаете, что пакет хоста не активируется на неправильной операционной системе, а объявление Nix разрешается через нужный вам реестр. Если проект хранится в Git, саму конфигурацию следует проверять как код. Она может устанавливать пакеты, менять активацию shell, создавать сервисы, записывать файлы и запускать hooks.

Разумная последовательность выглядит так:

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

Применять конфигурацию стоит только после того, как вывод стал понятен. В CI для автоматического запуска доступна команда mise bootstrap --yes, но неинтерактивный флаг убирает шаг подтверждения, а не делает недоверенную конфигурацию безопасной. Там, где важна повторяемость, закрепляйте версии или ревизии источников и держите CI lock-файлы под ревью.

Для Nix официальная документация требует Nix 2.24 или новее, включённые nix-command и flakes, а также современную поддержку nix profile. Сокращение nix:ripgrep разрешается через nixpkgs-реестр машины. Значение latest означает то, что этот источник предлагает сейчас; это не lock. Если сборку нужно будет восстановить позднее, используйте источник с закреплённой ревизией или зафиксированную запись реестра. Pin версии пакета вроде nix:ripgrep@14 этим бэкендом не поддерживается.

Документация отдельно подчёркивает, что mise не инициализирует и не переносит старый профиль Nix. Если машина сообщает о прежнем формате профиля nix-env, это административная задача Nix, которую нужно решать отдельно. Инструмент не удаляет профиль и не конвертирует его молча. Это хорошее свойство безопасности, хотя пользователи, ожидающие миграцию одной командой, могут удивиться.

Что это не заменяет

mise 2026.9.4 хорошо подходит, когда задача состоит в координации уже существующих инструментов. Он менее убедителен, если главным требованием являются герметичная сборка или неизменяемая система. Nix flake умеет закреплять входы и описывать оболочку разработки с более глубоким контролем над графом зависимостей и вычислением конфигурации. devenv строит поверх Nix ориентированный на разработчика слой, включая сервисы, задачи, поддержку языков и lock-файлы. Контейнер или devcontainer может дать более строгую границу для CI и подключения новых участников.

Полезно сравнить mise и asdf. asdf прежде всего является менеджером версий нескольких рантаймов с системой плагинов и файлом .tool-versions на уровне проекта. Это более простой выбор для команд, которым нужны одинаковые версии языков и автоматическое переключение, но не нужна более широкая модель начальной настройки машины. direnv решает другую часть задачи: загружает изменения окружения при входе в каталог. Его можно сочетать с mise, Nix или другими источниками окружения.

Выбор должен зависеть от задачи, а не от числа интеграций. mise стоит использовать, когда репозиторию полезна единая конфигурация для рантаймов, задач, переменных окружения и аккуратно ограниченной настройки хоста. Нативный Nix подходит, когда на первом месте воспроизводимость и контроль над графом пакетов. devenv уместен, если команде нужно окружение разработки на базе Nix с высокоуровневой настройкой сервисов и рабочих процессов. asdf достаточен, когда требуется только управление версиями рантаймов. direnv решает проблему, если главным недостатком является автоматическая активация окружения. Эти инструменты могут сосуществовать, но пересечение владельцев PATH, версий языков и shell hooks часто приводит к труднообъяснимым сбоям.

Границы безопасности и доверия

Релиз имеет открытый исходный код, репозиторий распространяется по лицензии MIT и содержит опубликованную политику безопасности. Подписанный тег релиза и проверка манифестов Packslip полезны как сигналы в цепочке поставки, но не устраняют риски исполняемой конфигурации. Подписанный бинарник mise может добросовестно применить вредоносный mise.toml: проверка подписи доказывает происхождение артефакта, но не подтверждает уместность запрошенного репозиторием пакета, hook-а, сервиса или изменения файла для вашей машины.

Bootstrap прямо рассчитан на потенциально разрушительные действия. Команда может устанавливать пакеты, менять файлы активации, управлять сервисами, обновлять репозитории, записывать dotfiles и запускать задачи. Поэтому важны этапы dry run и trust. Не следует автоматически доверять репозиторию только потому, что он публичный или его конфигурация короткая. Прочитайте hooks, проверьте удалённые URL, имена пакетов и команды, которые используют повышенные привилегии или меняют запуск shell.

У Nix есть собственные решения о доверии. Реестры, бинарные кэши, substituter-ы, доверенные публичные ключи и входы flake влияют на то, что будет скачано и собрано. Интеграция mise использует существующую конфигурацию Nix, а не создаёт отдельную модель доверия. Это удобно, но проверка безопасности не может заканчиваться на файле mise. Командам стоит документировать принимаемые реестры и кэши Nix, а также способ закрепления ревизий источников.

Активная разработка проекта — ещё одна причина внедрять релиз постепенно. Версия с большим числом кроссплатформенных изменений может исправить реальные сбои и одновременно выявить краевые случаи в shell, пакетных менеджерах или архитектурах, которые сопровождающий не мог проверить локально. Начните с машины разработчика, затем проверьте чистый CI-раннер и только после этого расширяйте внедрение. Сохраняйте прежний путь настройки, пока новый процесс bootstrap не покажет, что окружение можно предсказуемо удалить и воссоздать.

Кому стоит попробовать релиз сейчас

Лучшие кандидаты — команды, уже использующие mise и накопившие отдельные инструкции для Homebrew, apt, Nix, dotfiles или тестовых сервисов. Больше всего они выиграют от селекторов окружений и различия между «объявлено» и «установлено». Хорошим вариантом будут и репозитории, рассчитанные на macOS и Linux, особенно если разработчикам нужны одинаковые имена задач проекта при разных нативных пакетных менеджерах.

Релиз стоит проверить и сопровождающим проектов, где много консольных инструментов. Man-страницы Packslip, подписанные манифесты, платформозависимые lock-файлы и улучшенный выбор артефактов затрагивают детали ежедневной работы, а не только демонстрационный сценарий. Проект, распространяющий собственные инструменты, может проверить, стали ли управляемые версии одинаково вести себя в разных shell и на разных платформах.

Менее подходящая аудитория — команда, которая ищет автоматическое и незаметное изменение машин. mise делает настройку понятнее, но не безрисковой. Объявление latest также нельзя принимать за гарантию воспроизводимости. Новый бэкенд Nix — это мост между декларацией уровня проекта и нативным пакетным менеджером, а не магическая абстракция, стирающая семантику самого менеджера.

Итог

Главное в mise 2026.9.4 — способ сделать зависимости хоста условными и пригодными для ревью. Поддержка Nix ценна тем, что уважает модель владения Nix, а селекторы env решают практическую проблему репозиториев с несколькими режимами работы. Поддержка man-страниц и изменения блокировок укрепляют менее заметные части управления инструментами, а кроссплатформенные исправления делают релиз значимым для CI, а не только для локальных shell.

Попробуйте его, если ваш текущий процесс уже похож на набор файлов рантаймов, скриптов пакетных менеджеров, определений задач и инструкций для разных окружений. Начните с небольшой конфигурации, используйте пробные запуски, закрепляйте всё, что должно повторяться, и оставляйте системные определения Nix или контейнеров главными там, где это необходимо. Для простого менеджера рантаймов mise может оказаться избыточным. Но для команды, которая хочет сделать всю настройку разработчика понятной, не притворяясь, будто все операционные системы одинаковы, это заслуживающее проверки обновление.

Источники

В исходной статье использованы материалы релиза mise 2026.9.4, документация по bootstrap-пакетам и Nix, описание проекта mise, сведения о лицензии и политике безопасности, а также документация asdf, direnv и devenv.