modules/nixpkgs: init

[MattSturgeon]

WIP draft to fix #1784

• copy-paste the nixpkgs module from nixos
• format with nixfmt
• strip out irrelevant bits
• replace our defaultPkgs special arg with pkgsPath

TODO

• Move nixpkgs module to top-level modules
  • Inherit _module.args in files submodules
• Correctly handle the current behaviour of using the host's pkgs instance
  • For standalone, we can do this if pkgs is passed to makeNixvim
  • For module wrappers, we can introduce a useHostPackages option (default true for now)
  • We could later deprecate this option in favour of users doing programs.nixvim.nixpkgs.pkgs = pkgs themselves?
• Remove deprecated options copied from nixos
• Update option docs
• Take inspiration from hm/darwin tweaks
  • One implementation allows the path to be overridden
• Re-evaluate how wrappers pass in pkgs

[MattSturgeon]

Getting this because I'm not yet setting a default for nixpkgs.system in all places.

error: Neither nixpkgs.hostPlatform nor the legacy option nixpkgs.system has been set.
You can set nixpkgs.hostPlatform in hardware-configuration.nix by re-running
a recent version of nixos-generate-config.
The option nixpkgs.system is still fully supported for NixOS 22.05 interoperability,
but will be deprecated in the future, so we recommend to set nixpkgs.hostPlatform.

This is making me think we should be re-evaluating how we decide which pkgs and lib to use. Up until now we've preferred using whatever is used in the host environment, and for standalone asking the user to supply a pkgs.

However I'm thinking it may make more sense to use the lib from our flake's inputs and default to importing nixpkgs also from our flake lock, but allow users to override the pkgs source and/or pkgs itself using this new module.

[traxys]

It was a conscious decision to use the pkgs imported from the environment, changing this would be a huge breaking change, as it would break all nixpkgs overlays defined in home-manager or nixpkgs.
We could do something like home-manager that has toggles to choose if it uses it's own nixpkgs, or if it uses a system provided one.

[MattSturgeon]

Yeah, it is definitely a breaking change, that's why I was kinda reluctant in my earlier comments.

I'm a bit more convinced now though. I also think we could come up with a reasonable deprecation strategy too.

Right now I'm just exploring the implementation; I'll probably open a smaller PR with the initial subset of changes soon.

I believe our current approach of inheriting the host module's nixpkgs instance is one of the major contributing factors to mismatched nixpkgs lock issues.

As for a way to toggle using the host's pkgs or not, I agree that's something we can do. It would also be something users can do manually:

{ pkgs, ... }:
{
  programs.nixvim.nixpkgs.pkgs = pkgs;
}

So maybe it's better to just document that rather than add wrapper-specific options to do it automatically?