Robert Hensing

I'd previously opened https://github.com/NixOS/nixpkgs/pull/231940 with the idea to import from that, but I've since realized that Nixpkgs needs an exception, because `imports` will fetch it eagerly, and that's a problem...

`overlays` must be disallowed by default, because they are simply too risky, especially as otherwise any module could define any attribute in it, affecting all `callPackage`, without the flake author...

This will trade a bit of learning for quite a bit of convenience. Possible downsides: - fewer people may learn to use `config` - this adds yet another way to...

> any docs Not much beyond "config, options, lib, ...: standard module system parameters." This assumes experience with the module system, which is not something I can assume anymore as...

In your example, you could still import at the `perSystem` level, but for consistency, reusable ones should be written for the "top level", as that is the more powerful one....

Interesting project btw. It would be interesting to turn the template into a reusable module. That way you could achieve a new level of user-friendliness, if you capture the most...

And unlike with a template, existing users will benefit from improvements.

Made a start with that in `start/index.html` earlier. Don't ask me why I wrote that in raw html :joy:; #31

It'd make sense for `nixpkgs.flakeModule` (TBD) to set a `mkDefault` for `systems`, as well as provide `nixpkgs.*` options for initializing `pkgs` differently, similar to how NixOS does it, but without...

This can be resolved by Nix not requiring the enumeration of supported systems - https://github.com/NixOS/nix/issues/7709 Alternatively, or in addition, a `nixpkgs` flake module could set a default value. `nixpkgs` does...