Yep, with a Turing-complete DSL, there's never just one way to do something in Nix. I find the interaction between modules and overlays particularly quirky, and tricky to replicate from public configs that make advance uses of both.

That said, I do appreciate being able to git blame into public configs, as most will include insightful commit messages or references to ticketed issues that include more discussion with informed community members you can follow up with. Being able to peek at how others fixed something before and after helps give context, and with the commits being timestamped, it also helps gauge current relevancy or chronological order to correlate with upstream changelogs.

Are you using flakes with lock files, or nixpins to fix down the hashes of your nix channel inputs? I like fixating my machines to the same exact inputs so that my desktop can serve as a warm local cache when upgrading my laptop.

Thank you for the detailed reply, much appreciated!

Any rough edges you've encountered yet? Like using USB peripherals, or networking shenanigans? I'm assuming it's using the host network driver by default, and maybe bind mounting /dev/bus/usb for USB pass through?

Think I'll really dig into distrobox today.

You inspect the /proc file tree or ps utility command:

• https://www.baeldung.com/linux/process-environment-variables

Do you know of a complete example or live config I could read through as a reference for that first method recommended?

I'd also be interested in complete examples for a working pair of remote builder and local client (both NixOS multi user), as all the documentation I've come across thus far are either:

• intent on modifying root ssh configs in spite of security practices

• botch use of substituters on the remote builder

  • causing needles recompilation, ignoring upstream cache.nix.org

• is awkward or incompatible with non-interactive sudo sessions

• works for nixos build but not to switch

• https://nix.dev/manual/nix/2.30/advanced-topics/distributed-builds

• https://wiki.nixos.org/wiki/Distributed_build

• https://discourse.nixos.org/t/nixos-rebuild-use-remote-sudo-prompts-me-for-a-password-3-times/56003

• https://discourse.nixos.org/t/remote-nixos-rebuild-works-with-build-but-not-with-switch/34741

If you just want to quickly create a local python develop environment on the side using Python module metadata, installing uv from nixpkgs, and enabling nix-ld to run pre-compiled binaries from PyPI keeps things simple, and replicating the same virtual python environment workflow you to have on any other distribution:

https://discourse.nixos.org/t/i-want-understanding-nix-packages-and-flake-basics/67365/3

If you wanted to package a python module for nix or for proper distribution via nixpkgs, you'd want to add a nix derivation file that encapsulates all the inputs, i.e. software building materials (SBOM). There are existing nix library functions that can automate most of the packaging, not unlike Debian macros:

https://wiki.nixos.org/wiki/Python

The second approach is more rigorous, and combined with something like flakes for pinning the exact hash for all inputs via lock file ensures reproducibility, like when sharing with other nix users. While as the first approach is more subject to your current system, i.e. linking to whatever system wide libraries are presently installed, but it's less upfront effort to reuse existing python-package-managers than to nixify everything.

Thank you for your work!
I would not have liked encountering this bug in the wild.

I'll preface that NixOS may not be for everyone, as deviating from a conventional hierarchical file system is a radical departure from conventional distributions; but for those that want precise control over their system environment, it has a good deal of appeal.

For example, I appreciate being able to use the latest bleeding release of a number of tools while sticking with older trusted versions of other utilities, but if both relied upon different versions of similar dependencies, such package conflicts can be troublesome to resolve, as few Linux package managers gracefully deal with multi version installs.

For NixOS using the nix store, installing leaf packages that traditionally conflict is trivial, and as a user, I can spend less time managing every transitive dependency in order to use the software I want. Not having to wait for a disjointed ecosystem of packages to synchronize around dependencies, or resorting to compromise in package version selection is very liberating.

• https://nixos.org/guides/how-nix-works/

The functional language and documentation for nix itself is a bit quirky, as I wish it was stronger typed, but being able to declaratively express and version control my setup across workstations has been a time saver; installing/configuring something once and then have-done with it.

Nix-ld is only used by unpatched executables that use the link loader at /lib or /lib64. If you use for example python from nixpkgs than it will not pick up NIX_LD_LIBRARY_PATH and NIX_LD since these types of binaries are configured to use a glibc from the nix store.

• https://github.com/nix-community/nix-ld/blob/bc1a7a1b88589bfd26846fc5341fe44fc73b3fbd/README.md?plain=1#L164

Ah, I guess that's why I've seen folks recommend just having uv install the python interpreter as well, so everything python uses the same link loder from nix-ld.

I would have liked the PyCon25 talk directly, but I don't think the recordings have been published yet:

https://slides.com/bittner/pycon25-nixos-for-python-developers#/2/4

Hopefully the presenter discusses more on their later slides in using python on NixOS and working around python packaging's use of dynamic linking.

I'd love to find an example NixOS config to simply reproduce and import Clear Linux's kernel config. There are a few already for replicating CachyOS's kernel variants:

• https://github.com/chaotic-cx/nyx/tree/main/pkgs/linux-cachyos/config-nix

Although I'm not sure that those approachs still use clang instead of gcc?

Looks like the script author is asking for advise on how to provide it as a theme. Perhaps you might be able to help them with just that:

• https://sh.itjust.works/post/304585

For posterity, I later stumbled upon the authors original post here:

• Tamper/Greasemonkey script to reformat interface to a style recalling old.reddit
  • https://sh.itjust.works/post/53395

The community that this was posted from also looks interesting:

• Lemmy Plugins & Userscripts
  • https://sh.itjust.works/c/plugins