Not sure why it slipped my mind until now, but I’ve ~recently suggested thinning out modules a little by pulling more configuration logistic code towards the packages (i.e., moving it into passthru functions).
This could benefit Nth module systems and help with things like generating a config for some server you just need to run in a shell.
That’s also what RFC 78 is about, though I don’t know if using the package attributes for it leads to the best outcome. In most cases your config file would depend on too much. For instance you have to know in advance which package you’re going to use, even if the config file doesn’t depend on the package version at all.
Another issue is strictness. By putting the generator on a package attrset you need to evaluate the package first, even if you don’t actually need the package. This could make performance worse and cause some unnecessary errors, like if you’re generating the config file using a platform that the package doesn’t support.
Usually not a problem, but really annoying when it is.
Hm, if it is added via //, won’t the override level be checked first with mkDerivation call not even made if the override level already sets the config generator function attribute?
This is about strictness. Nix doesn’t have good terms for this so let me define
e1 is called strict in e2 when returning the weak head normal form ofSo with that out of the way, strictness of a // b is easy to answer: it is strict in both a and b.
That means that pkg // { generateConfig = ...; } is strict in pkg.
pkg itself will be strict in many things, including all the mkDerivation argument attribute names and some of the values, notably including outputs, and the assert statements that precede it in the package nix file.
Most of these sound about right, but I’m a little unsure how to read this bit:
Is this a generic “you” that just describes what Nix needs to know to evaluate the config, or is “you” an end-user who needs to directly reference a package in their NixOS config in order to manage its settings?
If the latter, I should clarify that I’m imagining a transparent refactor (to abstract out reusable bits) from the perspective of someone using/configuring a module.
Both "you"s, kind of.
Nix needs to evaluate the package, and we don’t really know who the “end user” of the function is and whether they can decide what the package should be. Both reasons can become a problem.
Maybe they only want a config file and no package, because the package they want is already in the docker image they’re building, or whatever.
A “stand-alone” function - one that doesn’t have the package in its arguments or scope - doesn’t suffer from this problem.
Maybe the stand-alone function needs to know the package version, but that’s still no reason to depend on the whole package, and most functions don’t even need this.
transparent refactor
I think that’s what we’re all going for. The only disagreement is about how it’s factored out, and where it then ends up. Splitting a module is morally equivalent to factoring out a function.
For the end users they’re equally transparent, but factoring out a module follows less familiar rules, and has more value because you get to reuse the option declarations. (And even better if you use the imports into submodule pattern)
But now I’m just repeating the RFC 78 discussion.
It could use some summarization and clarification, but I don’t think this is the time and place, if that’s ok.
For reference, something like kFreeBSD seems unlikely to gather a sufficient mass of contributors: Aurélien Jarno - Goodbye Debian GNU/kFreeBSD
I would love to have NixBSD as an alternative to NixOS, but I wouldn’t want to see NixOS adapted to use the FreeBSD kernel. All I want are derivations to build FreeBSD and modules to manage its configuration. Trying to do anything more than that risks creating a variant with no community to support it (which seems to be what happened to Debian GNU/kFreeBSD).
I have thought a lot about the failure of that project. I think the reasons we are different is that:
The goal of a NixOS with some BSD kernel isn’t even just BSD per-se, it is to open the floodgates to kernel experimentation in general. We should also get RedoxOS, SerenityOS, and many other things thereafter. I have no doubt that the sum total of all these things will be compelling.
N=1 to N=2 is the hardest transition, and BSDs are simply good mature candidates to make that initial leap. N=2 to N=3 and beyond is quite easy, and ideally by slowly expunging architecture issues the whole thing pays for itself (e.g. stuff like sharing NixOS modules between Home Manger and Nix Darwin is also helped).
“Opening the floodgates” was my experience with the Nixpkgs-side work, and now I just want to repeat that with NixOS.
Debian certainly does have high barriers for contribution, at least generally (I’m not so sure about ports).
Yeah our basic MO has always been
That applies to many of our projects, and specific initiatives within them, alike. It’s what we do best.
Debian stumbles at every step and therefore can’t get to step 5 without a huge stroke of luck.
This feels like it belongs in a ~gentle manifesto somewhere 
Support cross compiling to BSD and CI it by Ericson2314 · Pull Request #8887 · NixOS/nix · GitHub Making sure cross-build Nix itself is cached and not bitrotting!
Actually using cross-built Nix on BSD is still left as an exercise for the reader 
For the record, NixBSD exists now:
It should be put under the NixOS umbrella, I would say. Or at least under nix-community.
It’s high up on my priority queue to get the Nixpkgs and Nix work of @rhelmot for this upstream. That would just leave the NixOS-inspired part separate (hopefully to someday be merged with regular NixOS!).