naersk VS dotfiles

i would also recommend using crane or naersk since iirc rustPlaform.buildRustPackage can mangle some of these options (or maybe i just did something wrong lol)

Have a look at naersk, it neither requires generated Nix files nor IFD.

We use naersk[0] for Rust projects in our Nix monorepo (for example [1]). It's pretty hands-off in terms of the Nix code needed (you don't need to pin hashes inside of the Nix code as long as you have a Cargo lockfile) and all the existing tooling keeps working fine.

The main drawback of it is that it currently builds all of your dependencies in one big derivation, so any dependency changes cause a full rebuild. There's some other project I saw fly by which attempts to do a similar thing but split each crate into a separate derivation, but I forgot what it's called and have no experience with it.

[0]: https://github.com/nix-community/naersk

[1]: https://cs.tvl.fyi/depot/-/blob/ops/journaldriver/default.ni...

You can also use naersk¹ if you want to avoid a two-step process. It's especially convenient when using nix flakes.

¹https://github.com/nix-community/naersk

I created https://github.com/nmattia/napalm/issues/34 and https://github.com/nmattia/naersk/issues/183 to move them to nix-community

sounds exactly like what naersk does. naersk doesn't need a cargSha256 argument since it downloads dependencies from Cargo.lock. it can also grab the version number from Cargo.toml

Not sure about central but just search dotfiles, config, or flake on GitHub and filter by nix language. Most dotfiles are a sort of “distro” as nix let’s you configure everything from scratch in a central way. Eg my personal dotfiles are an abstracted layer of NixOS/home manager. This can be seen honestly in a lot of popular configs. Eg my WireGuard module turns high level options into automatic configs (see: module).

What’s powerful about nix is the language IMO. I was able to build an automatic WireGuard setup[1] with tagging that automatically works on each new machine thanks to the ability to do config as code. Just provide some basic config for each machine and the code turns it into an interface with peers.

The issue to me isn’t the language persay (it’s really a tiny surface area language, see the built in/lib functions [2]) but the tooling built around packaging is a hodgepodge mess of semi-documented workarounds (with Nixpkgs blessed ways vs used libraries) and is extremely difficult to approach and understand.

[1]: https://github.com/jordanisaacs/dotfiles

Not entirely sure what you mean by policies. But you can use rycee’s buildFirefoxXpiAddon. All you need is the xpi. See: https://github.com/jordanisaacs/dotfiles/blob/master/modules/users/graphical/applications/firefox.nix for some manual packages.

As a heads up setting up gnome-keyring is an adventure in and of itself when not using GNOME which from the sounds of it you are not. It took me a month of on and off trial and error to finally quash the last of its bugs. You can search around my dotfiles where I have it working but the solutions are all over the place (modules/system/gnome/default.nix, modules/users/graphical/shared.nix, and modules/users/graphical/wayland.nix).

I’ll just add on, I use functions in my nix file to make configs (iso, home manager, nixos),: function folder. With this logic you can create basic other hosts. How they are used in used in flake.nix

I am using this repo as a guide. I created a module which has the bootloader and filesystems configuration, and here I would like to conditionally load the qemu guest configuration, based on a configured attr. When you install NixOS in a qemu vm, this import is automatically added by nixos-generate-config to /etc/nixos/hardware-configuration.nix like so: