Nix packages (nix)
The nix manager installs packages into your user's Nix profile with nix profile install. It works on Linux and macOS, on NixOS or not. To add the packages to a NixOS system configuration instead, export them.
[bootstrap.packages]
"nix:ripgrep" = "latest"
"nix:jq" = "latest"
"nix:python3Packages.pip" = "latest"mise bootstrap packages apply --manager nix --dry-run
mise bootstrap packages apply --manager nixThe packages belong to your Nix profile, not to a project. They use the normal Nix profile PATH setup, get no mise shims, and never need sudo.
Prerequisites
The manager is available on Linux and macOS when nix is on PATH. Use Nix 2.24 or newer with the nix-command and flakes features enabled in your Nix configuration. The profile must use the nix profile format; mise reports an error for a legacy nix-env profile and does not delete or migrate it.
mise uses your existing Nix registries, substituters, and trusted keys. It does not install Nix, configure caches, or update flake lock files. Nix may build a package from source when no configured cache has it.
Package names
A shorthand name such as ripgrep or python3Packages.pip is an attribute path resolved through the machine's nixpkgs registry entry. To use another source, write an explicit flake reference and attribute:
[bootstrap.packages]
"nix:my-packages#hello" = "latest"
"nix:path:/absolute/path/to/flake#hello" = "latest"
"nix:github:NixOS/nixpkgs/<revision>#ripgrep" = "latest"Replace <revision> with a real commit. Relative paths, Nix expressions, and ^output selectors are not supported.
Version pins
Nix packages have no version pins: nix:ripgrep@14 is rejected, and a version in the value is reported as a mismatch and skipped. "latest" means whatever the source currently supplies. To keep the same package set, pin the source instead, with a revision in the flake reference as above, or by pinning the registry entry, for example with nix registry pin nixpkgs.
What mise runs
| Operation | Command |
|---|---|
| Check installed state (no sudo) | nix profile list --json --offline |
| Install | nix profile install -- nixpkgs#<attribute> |
apply --update | nix profile install --refresh -- <references> |
| Upgrade | nix profile upgrade -- <matching profile entries> |
apply installs missing packages and leaves other profile entries alone. It does not update an installed package from a moving source; upgrade does. A source pinned to a revision stays pinned.
Status matches profile entries by source and attribute path, not by looking for an executable on PATH. Its installed-version column shows Nix store paths. Status and dry runs do not create a profile or fetch package sources.
Remove packages
mise does not remove Nix packages, and state = "absent" and prune are not supported. Deleting an entry leaves the package in your profile; use nix profile remove or roll back with nix profile rollback.
Export to NixOS
To make packages part of a NixOS system configuration instead of your user profile, add the declarations without installing them, then export a module:
mise bootstrap packages use --no-install nix:ripgrep nix:jq
mise bootstrap packages export --format nix > packages.nixThe module refers to the pkgs of the configuration that imports it:
# Generated by mise bootstrap packages export --format nix
{ pkgs, ... }:
{
environment.systemPackages = [
pkgs."jq"
pkgs."ripgrep"
];
}Put packages.nix next to your NixOS configuration and add ./packages.nix to its imports. If the configuration is a flake in Git, add the file to the repository so flake evaluation can see it. Then rebuild as usual, for example:
sudo nixos-rebuild switch --flake /path/to/system-config#hostnameexport does not need Nix and does not build, install, or activate anything. It reads the declarations active for the current platform and environment, honors system_packages.managers, and leaves out state = "absent" entries. Only shorthand attribute paths can be exported: an explicit flake reference or a version pin fails before any output, because the importing configuration owns the package set and its pins.
After you remove a declaration, export and rebuild again; another module may still install the package. Packages in your user profile are separate from the system configuration and are not rolled back by switching NixOS generations. Do not also run apply on declarations you export, because apply installs them into your user profile.