Developing for NixOS

Help
1

What do developers have to consider if they want their software to run under NixOS? Or how NixOS contributors can provide patches upstream.

Most developers probably don’t care because NixOS has not many users, but we can argue with general portability. When it works on NixOS, it should work everywhere.

A guide on this topic would be great, so please provide some examples here.

Provide instructions for install from source

Not only Docker, Flatpak or whatever.

That way the project can get packaged for more systems.

In best case, it’s just:

./configure
make
make install

List all dependencies

Even when you think they are common on all systems. They actually may not and not everyone uses Ubuntu like you.

Make releases

Even when your software is not stable yet. It helps to package a known good state.

Use semver when possible.

Hardcoded paths

Use #!/usr/bin/env bash instead of #!/bin/bash or #!/usr/bin/bash or whatever in your bash scripts.

Same with #!/usr/bin/env python.

Use $XDG_DATA_DIRS instead of /usr/share/.

Make the install PREFIX configurable.

3 Likes
2

Make installation paths overridable

Ideally following GNU directory variables standard.

I also made similar list intended for projects using CMake, which are, in my experience, often one of the worst low-key portability offenders: GitHub - jtojnar/cmake-snips: Portability problems I frequently encounter in projects using CMake

3 Likes
3

I’d also like to add something “inspired by” Microsoft and many of their vscode extensions in particular:

Let the user change where binaries come from.

If you insist on downloading dynamically-linked binaries at runtime, at least allow the user to force looking them up in $PATH instead so they don’t have to patchelf every binary after every upgrade. This is admittedly rather NixOS-specific, but would probably also help other distros which don’t use glibc or have the dynamic linker in some non-standard place.

1 Like