`specialArgs` considered harmful
4 points by ysun
4 points by ysun
This seems like a problem you only have if your nixos config flake depends on someone else's nixos configs, which seems like a weird thing to do in the first place. If I did want you to consume my modules, I'd export them in nixosModules in the proper form so you could use them at the standard interface point. If you go digging past that standard interface to copy files out, and you get bitten by my implementation details, that's your fault.
This seems like a problem you only have if your nixos config flake depends on someone else's nixos configs
i mean this article is targeted to those who maintain public modules, for downstream users (in the sense of you can make sure no one will depend on your nix code), using special args is generally fine
someone already responded to a similar question here as well: https://discourse.nixos.org/t/specialargs-considered-harmful/80465
I'm having some fun with my own Nix config by swapping flakes for npins, and I build using a wrapper script that basically does:
NIX_PATH="-=$PWD" nix-build ...
That means I can import relative to the project root with:
import <-/foobar>
Plus get straight to my dependencies from anywhere with:
let sources = import <-/npins>; in ...
It also makes the build semi-hermetic, in that nothing can import <nixpkgs> anymore.
Now there are trade-offs both ways compared to flakes, but I kinda like the importing aspect of it, and wonder why flakes doesn't do any of this. Lots of JavaScript bundlers have tricks to do project-relative imports, and flakes could've easily overloaded the <> import syntax for similar functionality. And if it also made inputs reachable via <> somehow, you probably wouldn't need specialArgs or any of these tricks. I don't even feel like this is more arcane compared to some of the magic in flakes today.
most likely flakes will be even more magical pretty soon ;) my mom asked me not to ifd when evaluating flake.nix