How do you use your own nixpkgs forks?

I am new to Nix and in an intensive learning process through migrating all of my dotfiles to a single home-manager configuration on macOS, linux workstation and Win/WSL. During this process I’ve had to fork nixpkgs multiple times to add new packages there. Here come questions. Despite I use home-manager, I believe my issues are related to Nix package manager and nixpkgs more than to home-manager.

  1. If I only have one PR pending, I just use home-manager -I nixpkgs=<pr-branch>.tar.gz switch. I have to use pr-branch’s remote .tar.gz to easily share my additions with all of my workstations. The problem is when I push into pr-branch with some new additions/fixes I can’t just execute the command above again because Nix apparently caches remote channels so every time I need to be sure Nix downloads fresh version I come up with random string after ? sign: home-manager -I nixpkgs=<pr-branch>.tar.gz?brr switch. And if changes keep going it eventually becomes hard to come up with truly unique query param. I haven’t find any option to optionally disable Nix cache, ideally through home-manager’s cli. Is there more convenient workflow with own nixpkgs forks when then need to be tested and actually used on different hosts?

  2. It’s not uncommon situation when PR is pending for weeks. That’s ok and can be handled with a trick above. But very often there are two PRs not accepted to nixpkgs. Personally I create a branch in which I continuously merge my pending PRs. It becomes a burden when PRs keep being updated. I am considering to automate script for creating an immutable which is destroyed and created from scratch each time script is executed but before doing I decided to ask if there is an easier way to cope with this, maybe I’m overthinking the problem.

I just put the appropriate file to be included in my /etc/nixos directory

For your first problem, I think you might be able to just use the commit hash instead of the branch name.

But I’ve never used your inline home-manager method, instead I’ve used this in my configuration.nix:

  nixpkgs.overlays = [
    (self: super: {
      nomachine-client = (import (builtins.fetchTarball {
        url =
        sha256 = "08sghr19nas4mb74k88mvy4sq9zgb9m15lp0l11y56vx142j3lzg";
      }) { config = { allowUnfree = true; }; }).nomachine-client;

In this example it’s from NixOS org on GitHub, but it could be your own repo as well. I tend to do this for each package versus creating my own fork of nixpkgs and continually merging there.

I don’t use home-manager or overlays, only NixOS, and there I use multiple nixpkgs branches side-by-side - example at User:Raboof - NixOS Wiki . I’m not sure if this is a ‘proper’ approach but it works well for me - I’m curious to see other recommendations :slight_smile: .

1 Like

I don’t use home-manager yet, and tbh I either haven’t seen the need for overlays or maybe just don’t grok them yet.
I have my fork of nixpkgs just like you with a couple of pending PRs, each in its own branch, and then merged together in the master branch of my fork.
Then in my configuration.nix I import my fork to a variable pkgsPersonal and then use that instead of pkgs whenever I want to install something from my fork.
You can see my configuration.nix here, hope it helps: nixos-configuration/configuration.nix at 02a0bd0b9963568367fe0bb7256b4fcdfd5ab694 · mausch/nixos-configuration · GitHub

And yes, don’t reference branch names but commit hashes :slightly_smiling_face:

Like you I’m still learning Nix and while I appreciate its flexibility and power it also means that everyone does things slightly differently, which makes learning a bit frustrating. Even the official guides/blogs do this e.g. you’ll see some very recent posts using nix-shell but then you’ll read some people saying that nix-shell should be considered legacy :man_shrugging: I’d expect this from learning a new language but for some reason I didn’t expect it from learning a distro / package manager, though I should just probably adjust my own expectations!
The way I’ve been learning is to read lots and lots of the nixpkgs repo and other people’s configs. And of course lots of experimentation too :slightly_smiling_face: .


nix-shell is currently the only way to get into an isolated development environment without having to resort to flakes, which are experimental and very unstable.

I had a feeling that I can use nixpkgs’s for as an overlay but didn’t know how to narrow it down to a single package. Sometimes, line @mausch, I’m feeling lost in nixpkgs docs, wikis and community resources but I believe this feeling goes away when you start to think of nix as a programming language, not just configuration syntax.
I think that’s exactly what I need for both of described problems!
I suppose I can define multiple overlays for multiple packages pointing to different revisions of my forked repo.

Wish I stumbled upon your wiki a few weeks ago :slightly_smiling_face:

I clone the git repositories locally and have a system branch in each. This system branch contains the commits I want: e.g., for nixpkgs, my system branch will point to origin/nixos-unstable branch + 2 open PRs + a merged PR that is not yet in nixos-unstable. Then, I make nixos and home-manager point to git clones:

nix.nixPath = [
    # Configure NIX_PATH so it search <nixpkgs> in my clone of the git
    # repository. For this to work fine, it's better to remove all
    # channels:
    # $ nix-channel --list # should print nothing
    # $ sudo nix-channel --list # should print nothing
    # Remove channels with:
    # $ nix-channel --remove
    "nixpkgs=${builtins.toString /path/to/nixpkgs}"
    "home-manager=${builtins.toString /path/to/home-manager}"