DBCDK
Document the version of NixOS/Nixpkgs supported in conjunction with Morph
I started using Morph at 3856a9c2f733192dee1600b8655715d760ba1803 and stuck with that version for quite a while. For whatever reason, it happened to build with the version of Nixpkgs on my system and be compatible with the version of NixOS I was trying to deploy.
Time passes.
I realized I didn't like depending on a particular version of Morph that I happened to have checked out one day a year ago to manage my deployment. I tried pinning a Morph version in a shell.nix and optimistically tried updating to the newest version. It failed to build with my Nixpkgs. So I guessed it would probably be happier with nixos-unstable (as that seems to be what the in-repo dev environment setup wants). It built but it couldn't build my configuration. Depending on exactly what version of Morph I pin, I get different errors, but they're generally along these lines:
The option `documentation.nixos.extraModuleSources' defined in `<unknown-file>' does not exist.
ie, some NixOS option is being set in some incompatible way.
This makes some sense. morph tries to configure NixOS a bit. It will therefore have some dependency on what version of NixOS is being deployed. However, how is the end user to know which version(s) of NixOS a particular version of Morph can be used with? Unlike the Morph development environment, I don't just want to allow NixOS to float with HEAD on github - I want to control that version and only upgrade it after I'm confident the upgrade doesn't introduce regressions into my system.
Please add to Morph (documentation, CI, something) a NixOS version range where it is known to work so that a compatible version can be selected to go along with the NixOS being managed.
Thanks.
I see that I have conflated what may really be two separate issues here. One is "What version of Nixpkgs can build a working Morph?" and another is "What version of NixOS can a version of Morph manage?"
On the former, here's one idea. Consider the current CI configuration. It currently lets Nixpkgs float (with nixos-unstable). This has the effect of testing a single version of NixOS which varies over time (outside of the control of Morph). Instead, Morph CI could take control of that variable. Extend the current CI configuration with a NixOS version dimension. Invoke shell.nix with each of several different NixOS versions (I imagine starting with two makes sense: nixos-20.03 and nixos-unstable). Okay. Strictly speaking, those are both still floating versions. I don't know if there's interest in continuing to support non-HEAD of any channels though.
Then document that these are the versions of NixOS that Morph builds on. The decision about when 20.03 support is dropped and what new xx.yy version becomes supported is independent but now it can at least be made explicitly. If anyone wants my two cents, I'd say supporting a nixos release for as long as nixos itself supports that release is probably beneficial to and unsurprising to users.
Just to add to this, I got this error even though I have a pinned version of morph and a pinned version of nixpkgs (from where morph comes) in all my configuration and nix shell. However I still got this error on a system that had not been updated for a while, I presume that morph uses nixos command. I think you should be able to override the nixos command that morph uses so you can pin it to whatever you want.
Could this be revisited? My morph config broke leaving me unable to push a new config to a very remote raspberry pi. I have pinned the nixpkgs import, but it still seems to fail somewhere in my ~/.nix-defexpr/channels/unstable/... due to not finding pkgs.stdenv.hostPlatform.isArch, even though it exists in the unstable channel that I have set in my environment and it definitely exists in the pinned commit.
