Nix is a functional package manager that can pin exact versions of language runtimes (and, more broadly, entire package sets) the way asdf (#33) does, but through a fundamentally different, declarative model - Nix expressions/flakes and a content-addressed store, rather than asdf's imperative asdf install <lang> <version> plugin system. It isn't representable in the manifest schema at all right now.
Depends on #16 - same reasoning as #32/#33: Nix-managed languages need to be opt-in alongside pyenv/rbenv/sdkman/direct system installs, which needs real --select/--exclude filtering. Nix's own package entries will carry tags: [nix].
Platform scope is narrower than asdf/rvm/uv - Nix has no native Windows support at all, and does not work under Cygwin or MSYS2 either (it relies on Linux-style namespaces/bind-mounts, or macOS's own mechanisms). This would realistically only apply to ubuntu2204.yml (native Linux) and macos.yml - windows.yml/cygwin.yml/msys2.yml are out of scope entirely, not just deprioritized.
Also worth flagging: Nix's own install is heavier than the others here - it sets up a system-wide /nix store and (on multi-user installs) a background daemon, not just a shell-rc PATH addition, so this is a bigger install footprint than rbenv/asdf/uv.
This is additive/optional - existing platforms already install each language fine without Nix. This is about giving manifest authors the choice of Nix where they want it and where it's actually supported, once #16 makes that choice actually selectable.
Nix is a functional package manager that can pin exact versions of language runtimes (and, more broadly, entire package sets) the way
asdf(#33) does, but through a fundamentally different, declarative model - Nix expressions/flakes and a content-addressed store, rather than asdf's imperativeasdf install <lang> <version>plugin system. It isn't representable in the manifest schema at all right now.Depends on #16 - same reasoning as #32/#33: Nix-managed languages need to be opt-in alongside
pyenv/rbenv/sdkman/direct system installs, which needs real--select/--excludefiltering. Nix's own package entries will carrytags: [nix].Platform scope is narrower than asdf/rvm/uv - Nix has no native Windows support at all, and does not work under Cygwin or MSYS2 either (it relies on Linux-style namespaces/bind-mounts, or macOS's own mechanisms). This would realistically only apply to
ubuntu2204.yml(native Linux) andmacos.yml-windows.yml/cygwin.yml/msys2.ymlare out of scope entirely, not just deprioritized.Also worth flagging: Nix's own install is heavier than the others here - it sets up a system-wide
/nixstore and (on multi-user installs) a background daemon, not just a shell-rc PATH addition, so this is a bigger install footprint thanrbenv/asdf/uv.nixas a new packagetype:inresolve_order.rb'sPACKAGE_TYPESscript:-based bootstrap running the official Nix installer (or the Determinate Systems installer, which handles multi-user setup more reliably), then per-language steps (e.g.nix profile install nixpkgs#ruby, or anix-shell/flake-based approach if per-lesson pinning is wanted)nix profile install) or full declarative environments (flakes/nix develop) - a bigger design question than the other version-manager issues, since Nix's real value is the declarative/reproducible model, not just "install language X at version Y"nixinscriptbox/config/README.md's "Version Managers" list, alongsidepyenv/rbenv/sdkman, with a note on its Linux/macOS-only scopescriptbox/scripts/verify_commands.rbneeds any change, or whether it already covers Nix-installed languages transparently (it detects binaries by name, not by install method)This is additive/optional - existing platforms already install each language fine without Nix. This is about giving manifest authors the choice of Nix where they want it and where it's actually supported, once #16 makes that choice actually selectable.