home-manager
home-manager copied to clipboard
modules/default.nix: Add useNixpkgsModule parameter
Description
Fixes #2701 by making it possible to disable the nixpkgs module with the unprivileged flake setup.
I also made this the default for lib.homeManagerConfiguration as I think it makes more sense for performance to use the pkgs input directly rather than reimporting it and copying config/overlays. I could change that back to being optional if desired, not sure.
The current requirement that homeManagerConfiguration take a stateVersion, homeDirectory and username arg feels weird to me as it prevents setting these in that user's configuration nix files (unless you mkForce). This is more often done this way and makes it easier to share the same configuration between use in nixos modules and use for the unprivileged flake setup.
I think it would be best if homeManagerConfiguration worked like this:
homeManagerConfiguration = { configuration, system
, extraModules ? [ ], extraSpecialArgs ? { }
, pkgs ? builtins.getAttr system nixpkgs.outputs.legacyPackages
, check ? true }@args:
import ./modules {
inherit pkgs check extraSpecialArgs useNixpkgsModule;
configuration = { ... }: {
imports = [ configuration ] ++ extraModules;
// removed the home.* settings here and removed the args for them
// they should be set in extraModules or configuration like all other hm config is
};
};
};
But that wouldn't be backwards compatible.
Checklist
-
[x] Change is backwards compatible.
-
[x] Code formatted with
./format. -
[x] Code tested through
nix-shell --pure tests -A run.all. -
[ ] Test cases updated/added. See example.
-
[x] Commit messages are formatted like
{component}: {description} {long description}See CONTRIBUTING for more information and recent commit messages for examples.
-
If this PR adds a new module
-
[ ] Added myself as module maintainer. See example.
-
[ ] Added myself and the module files to
.github/CODEOWNERS.
-
Reverted the flake.nix change, let's just add the extra flag to modules/default.nix since it's easy enough to write your own thing which imports it and I wasn't sure how to handle documentation/backcompat.
This should still be an improvement even if it's not as easy to use.
@rycee @berbiche is there anything I need to do to get this merged?
Most of what I wanted to do was done in #3037 (by just not being back compat which is cool), the only change left in this PR is adding a useNixpkgsModule option in modules/default.nix and it should be ready.
This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/nixpkgs-unfree-configs-not-respected/20546/10
Hi, sorry, this PR is ready to be merged but it would be great if the documentation mentioned this new option.
Doesn't look like there is anywhere to document it with the current structure. If you use the CLI you don't import this yourself so it's not exposed, similarly if you use the flake.nix lib.homeManagerConfiguration it's not exposed yet.
I could add it as an option to that and document it, although I was trying to keep this minimal so I could get it merged :thinking:
@berbiche added the option to lib.homeManagerConfiguration so it's exposed and documented it. I defaulted it to true, happy to swap that to false if that's preferred.
1 failing test in CI, it's also failing on master.
1 failing test in CI, it's also failing on master.
This has been resolved on master
Thank you for your contribution! I marked this pull request as stale due to inactivity. Please read the relevant sections below before commenting.
If you are the original author of the PR
- GitHub sometimes doesn't notify people who commented / reviewed a PR previously when you (force) push commits. If you have addressed the reviews you can officially ask for a review from those who commented to you or anyone else.
- If it is unfinished but you plan to finish it, please mark it as a draft.
- If you don't expect to work on it any time soon, please consider closing it with a short comment encouraging someone else to pick up your work.
- To get things rolling again, rebase the PR against the target branch and address valid comments.
If you are not the original author of the PR
- If you want to pick up the work on this PR, please create a new PR and indicate that it supercedes and closes this PR.
I don't have the energy to update this right now. I did more than a year ago when I opened it but it's taken so long going through reviews that it doesn't feel worth it.
Hopefully someone else can make a PR for this.
I created this StackOverflow question to help everyone figure this out for the various different scenarios of using Nix:
Since GitHub issue comments are structured more like a forum of endless posts sorted by time instead of a proper question & answer site.