Skip to content

staging: 2025-10-03 -> 2025-11-10#68

Merged
Frontear merged 36 commits into
mainfrom
staging
Nov 10, 2025
Merged

staging: 2025-10-03 -> 2025-11-10#68
Frontear merged 36 commits into
mainfrom
staging

Conversation

@Frontear

Copy link
Copy Markdown
Owner

I've let this staging cycle go on for a little too long. Originally, I was going to push the changes through around the time I setup GNOME to use Stylix, but then I started to get busy with school and stopped making big changes to my configuration (and also forgetting to push them onto master).

During the busy period, I made smaller changes (all while forgetting about the staging cycle), and then more recently I made a big change involving the usage of nixos-facter. Too many big changes in one cycle have now accrued, so I'd like to freeze all commits to staging until this PR has been merged.

Things Done

Apologies, but I'm not going to write out a full list of things that have happened. I'll highlight some of the major events in a brief list below:

  1. Module resolution was revamped to be faster and a little more structured. As a result of this change, many module.nix stubs were removed in favour of following the structured system, which is automatically traverse and imported.
  2. GNOME is now themed with Stylix. It uses its own theme rather than re-using the one from Niri, mainly because the Niri one has terrible colors. I only use it because it works very well with my terminal, but it might be time to change that one too.
  3. nixos-facter was introduced to my configuration, and a few modules which configured hardware details are now controlled by facter's detection. Alongside this, nixos-hardware was dropped entirely, since it's no longer really needed.

A full implementation of #53. I'm not going to explain the code itself because I feel that it is sufficiently self-documenting, but I will elaborate on some smaller details.

`lib.mkModules` is intended to enter from the top-level `modules` directory rather than for specific modules. This is because it takes full control of resolution by making the assumptions laid out in #53. The `nixosModules` exposed by my flake have been updated to reflect this.

I've also changed a lot of path construction in `lib.flakes` from using string interpolation to using concatenation. The main reason for this is because concatenation will respect the original value type and possibly avoid the idiotic flake copy semantics. To explain this further, when you try to interpolate a path into a string via `"${pathValue}"`, Nix will copy the path into the store. This can be a very expensive operation depending on whether it's a big file or not, and it's really annoying that it does this. On the other hand, concatenation will respect the original path type and concatenate it into a new path value, without performing the stupid flake copy behaviour. This avoids unnecessary I/O operations and potentially fragmenting files by grabbing them in their isolated contexts and not as part of the flake that they evaluate in.
That was stupid of me. I originally used them because they had more of the common binaries, but they didn't even work correctly for `inxi`. Case in point, it always failed to read PCI devices.
FHS VSCode is abysmal, it fails to interop with devshells, it cannot run priviledged commands from the terminal due to being in a container, its impure, etc. Instead, I want to fixup extensions where applicable directly, usually by referring to Nixpkgs derivations.
For some reason, the display information does not populate without this, even though we are using wayland.
The yubikey fixes are no longer needed since the respective PR has been merged. The nix settings I disabled were causing trouble during the build of this update, which tells me that these settings are not very good. I still want to set them, but I obviously did not pick good values, so I will need to deliberate on that further.
This achieves a very slight reduction of the flake inputs closure size.
This was a change made upstream in https://www.github.com/neovim/nvim-lspconfig/issues/3693. In a nutshell, `require("lspconfig").<lsp>.setup` is no longer the accepted way to configure language servers. Instead, one should use `vim.lsp.config.<lsp> = {}`.

The migration itself is fairly trivial, though we also need to throw `vim.lsp.enable("<lsp>")` to activate it.
Motivated by #38. The interface has also been slighly change to use `extraConfig` instead of `init`, but otherwise remains identical.

Eventually I'll want to improve this entire thing completely, but for now it's simply not an extensive priority.
Motivated by #49. This makes use of `zparseopts` which requires that the interpreter be changed from `bash` to `zsh`. Small other improvements were made, though the script functionality remains identical to before.

I'm considering creating a Rust multi-call binary instead to implement these applications, as otherwise their codebase is going to duplicate a lot of stuff (such as the `dry-run`, `verbose`, and `help` options, the log levels, etc). It might be better off to do that.
Eventually this should be moved to some common module that enables everything required for a Wayland environment.
This lets me explicitly pick the tiger-lake modules, which brings some better defaults and actually reduces closure size, since it doesn't need to pull extra things that are useless for my system.
It's possible for `nixpkgs.pkgs` to be set in configuration, which makes `nixpkgs.config` a useless option to check. As such, it's better to check that state directly through the instantiated `pkgs` instead.
I've actually explicitly chosen to not use the theme generated by Stylix, as I feel that the colors do not look very good. My current **Atomize** theme already perfectly matches my base16 definitions, so I don't see a need to switch things up for now.
Since fingerprints cannot be used to decrypt, GNOME keyring is unable to be decrypted at login and will instead pester the user for the password post-login. This is not an easy problem to solve from both practical and philosphical angles, so the best solution is to simply disallow it.
I'm honestly a little surprised I didn't catch this originally, especially since it was a core part of the specification I laid out in #53. To my credit though, I have faithfully followed that specification, and this wouldn't be the only snippet that doesn't have error-checking, so I'm not entirely sure if I should bother with this at all.
It is already set by the modules.
This project is incomplete, so it will not fully replace `nixos-hardware` at the moment, but the end-goal is to replace said project.

From what I can see right now, it perfectly replaces `hardware-configuration.nix`, so I have removed that for now.
Some in-tree modules needed to be written. I will look to upstreaming these at some point.
These particular modules only exist due to a lacking upstream module. Normally I would not hesitate to PR such modules myself, but I'm unfamiliar with the wider set of hardware that might be relevant for particular modules (such as detecting SATA SSDs for fstrim, or detecting the various different GPU types from Intel for graphics stuff). As such, I don't feel comfortable providing an upstream PR, since any PR I do make would be incomplete and probably not suitable for merging. I simply don't have the wide variety of hardware to test off of.
Nothing noteworthy to migrate this time around. I suspect most of the big changes have already made it into the release-cycle, and the final few are still churning in staging. Release cut-off is November 30th, only 20 days (3 weeks) away.

I would've loved to contribute to the release cycle, but alas, school is a full-time job in and of itself.
@Frontear
Frontear merged commit 20d0436 into main Nov 10, 2025
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant