Enforce matching nixpkgs and home-manager versions

[danth]

Using Stylix with mismatched versions Nixpkgs or Home Manager is a common cause of one of the following errors:

• Missing options since they were implemented in a newer release
• Failing patches since we target a specific version of a package

See #375 and #241 for example, and many more questions on the Matrix channel.

It shouldn't be too difficult to add a check against config.system.nixos.release, and its Home Manager counterpart. We can then ask the user to upgrade NixOS/downgrade Stylix rather than allowing it to fall through to a cryptic error.

[trueNAHO]

What about adding a warning in the documentation?

[danth]

That would also be helpful, although a check in code will also catch cases where someone didn't read the docs.

[trueNAHO]

Adding testbeds for every application (https://github.com/danth/stylix/issues/319) would avoid Stylix supporting upstream options that are not yet available through our flake.lock. This would simplify the process of figuring out when to update flake.lock.

[danth]

I agree, the version stored in our flake.lock should be guaranteed to work perfectly.

We still need to support people using slightly newer / older revisions to some extent, since updating nixpkgs regularly is important for security updates - so it's not reasonable to expect people to stay pinned to Stylix's lock file.

[trueNAHO]

We still need to support people using slightly newer / older revisions to some extent, since updating nixpkgs regularly is important for security updates - so it's not reasonable to expect people to stay pinned to Stylix's lock file.

What about periodic updates?

For example, I use 1 in my dotfiles. Since I am not very familiar with GitHub's secret policy, I am not sure whether the used permissions leak any GitHub secrets. But I have seen many Nix projects use a similar periodic update approach.

I could PR this, if you want.

[danth]

AFAIK that action doesn't trigger the GitHub Actions checks, since events caused by an Actions workflow can't trigger another workflow, so reviewing it's PRs would be inconvenient.

[trueNAHO]

AFAIK that action doesn't trigger the GitHub Actions checks, since events caused by an Actions workflow can't trigger another workflow, so reviewing it's PRs would be inconvenient.

True. The created PRs contain the instructions for manually triggering GitHub Action checks: https://github.com/trueNAHO/dotfiles/pull/9.

[Nebucatnetzer]

What about adding a warning in the documentation?

That would definitely help or use a versioned example in the documentation. I don't think it can be expected that people are using unstable by default.