documentation.enable = mkForce true; # space!
documentation.nixos.enable = mkForce true; # space!
networking.wireless.enable = mkDefault true; # confilcts with networking.networkmanager.eneable = true; - see error:
# Failed assertions:
# - You can not use networking.networkmanager with networking.wireless.
# Except if you mark some interfaces as <literal>unmanaged</literal> by NetworkManager.
Because they would be basically unconfigured and unusable. For now though, it does give you a working initial system from which you can nixos-rebuild.
Whether in general an SD image of a system is used this way, and whether sdImage as in NixOS does it’s job is another question.
If your claimed ‘mean use case’ is to be implemented, I don’t think it should override sdImage just because it has the unfortunate name that seems to implement a different use case that some users consider more common. If this were to be implemented it should be provided as a different option.
In that context, ‘installation device’ seems to make sense? Also I think it’s a valid use case: download a general-purpose NixOS SD image, flash it, pop it into your Raspberry PI and use it interactively.
Now, of course generating bespoke immutable SD images is also a great use case of Nix. Perhaps a better starting point than the installer images would be nixos-generators, though?
I think it’s reasonable to assume that neither of those upstreams would be very keen on light-hartedly establish dependency on (yet) another repository.
Therefore, so my reasoning goes, getting this fixed upstream does effectively lower adoption barriers all the way down stream. And that seems to be a prerequisite in good faith for my plan.
On the other hand nixos-generators are pretty featureful so maybe they’ve got a chance at entering that upstream inclusion scrutiny, that I refer to.
UPDATE: looking at this, that repository looks like a competing as well as complementary source of truth, but at any rate, with definite overlap. Hm … Why has everything to be so complicated?
I think I’ll be probably told: feel free to go ahead and fix the world … I’d hold up: would I be able to on my own? And if so, which I’m not confident of, spanning over how many project hops (that each reflect individual as well as shared, but different, realitites)?
I think this is a case of semantic shift over time. For example /nixos/modules/installer/netboot/ is not likely to behave as an installer, as this would be a bit opposite to the ideas of what netboot is.
I updated the PR and split the installer device from the bespoke base (similar as netboot is done multilevel). However I hope somebody can help me get this PR backwards compatible and help me find what (many) references need updating.