libnix

motivation

this libnix nlnet application i’ve made is meant to contribute to the nix ecosystem by making nix a generic cross platform backend for language specific package managers.

it consists of two parts:

1. nix on windows - port nix to windows
2. libnix PM backend - use nix as a backend for language specific package managers “PMs” (node, pip, cargo, …)

or in simpler terms, figuring out a way to make nix more attractive for the industry so can be used during development and not only for deployment afterwards.

introduction

nix, the purely functional programming language and package manager, has been around since 3. jun 2003 - roughly 20 years. yet there is no vast industry adaption of nix (or nixos). why is that?

in parts:

• most development is done from and sometimes also for the windows platform
• wrapping language specific PMs with nix is hard
• technology stacks are selected by the lowest common denominator
• running IDEs on remote machines is not a common practice

PC desktop OS usage

it is worth to have a look at the global market share held by operating systems for desktop PCs, from january 2013 to february 2024:

taking macOS + Linux together, nix could be used on ~20% of the desktops.

PC gaming OS usage

the valve steam statistics for march 2024 show:

• 96.67% windows
• 1.94% linux
• 1.38% mac

the gaming industry is a good early indicator for the general desktop usage with valve being a key driver in linux adaption together with AMD.

OS summary

the mission

given the motivation and statistics, the mission is to make software development more about development and less about package management. this will be done by using nix as a generic cross platform backend for language specific package managers.

nix on windows

before we go into a native nix on windows we have to look at nixos-wsl using WSL2.

nixos-wsl

using nixos-wsl with nixos-vscode-server via ssh is the most convenient way to work with nix on windows today. i’ve been using nixos-wsl a lot and it works for development and is much better compared to VM based development. that said, nixos-wsl is no replacement for a native windows experience, especially in regards to IDE integration and runtime performance.

native nix on windows

for historic reasons we should also mention the ternaris report from 2015 which outlines obstacles to overcome: https://ternaris.com/lab/. in parts this has been outdated but it still might be an interesting read.

if you want to join development for a native nix on windows, see these resources:

• https://matrix.to/#/#windows:nixos.org
• https://discourse.nixos.org/t/nix-on-windows/1113
• https://github.com/NixOS/GSoC/blob/main/ideas/2024.md

since nix is c++, bash and perl there are some things to consider:

• minGW
• cosmopolitan

or maybe start with the rust port of nix?

• TVIX

summary

the next post in the libnix series will cover the current status of nix on windows.

libnix - language specific PMs considerations

language specific PMs like npm, yarn, cargo, conan, pip, … are the most common way to manage software stacks in the industry. some of them are even cross platform already!

the main challenge here is how well these can be integrated with nix!

traditional wrapping

most PMs are wrapped using nix abstractions, see https://nixos.wiki/wiki/Language-specific_package_helpers and on program updates these need to be redone.

PM anatomy

language specific package managers (like cargo, npm) solve these problems:

• resolve dependencies
• using/creating lock files for toolchains and dependencies
• downloading dependencies
• manage build artifact caches (i.e. .cargo, .conan, .npm, …) for faster builds and garbage collecting them eventually
• build target program or library
• wrap native software like openssl, libxml for runtime or compilers like gcc for build time actions
• install routines for the target program or library

ideally this only means a manual run of some tool like node2nix but often times it means a manual patching of build scripts.

examples

these two projects have the concept of libnix already implemented:

• spack
• haskell

i will look into these in more detail in the next post about libnix series.

summary

windows nix support matters because then we can share package management concepts between operating systems. ideally we can make nix into a generic backend for PMs making software development great again!