I’ve been increasingly just writing nix flakes for my own projects.
I get a reliable project environment, even months down the line, and I get to present the final binary in an easy to use way (nix flake output), comparatively. I can even ship service configuration, making deployment as easy as adding the flake to your input, adding the flake module and then typing service.service-that-cultpony-wrote.enable = true;. Bam, deployed.
Oh and keeping things up-to-date is easy too; I just have a github action that runs nix flake lock --update-input <input name> for all inputs (you can do all inputs at once with nix flake update) and creates a pull request if things changed.
You don’t need to include a dependency of flake-utils if all you are doing is calling a for loop. Flakes will necessarily cause that dependency to be downloaded and managed for all downstream users. If you include the lines in flake.lock, it’s less code to inline that loop yourself.
I’ve been increasingly just writing nix flakes for my own projects.
I get a reliable project environment, even months down the line, and I get to present the final binary in an easy to use way (nix flake output), comparatively. I can even ship service configuration, making deployment as easy as adding the flake to your input, adding the flake module and then typing
service.service-that-cultpony-wrote.enable = true;. Bam, deployed.Oh and keeping things up-to-date is easy too; I just have a github action that runs
nix flake lock --update-input <input name>for all inputs (you can do all inputs at once withnix flake update) and creates a pull request if things changed.You don’t need to include a dependency of
flake-utilsif all you are doing is calling a for loop. Flakes will necessarily cause that dependency to be downloaded and managed for all downstream users. If you include the lines inflake.lock, it’s less code to inline that loop yourself.