nixos module imports separate <nixpkgs> #616
Comments
|
This is a pretty delicate matter. The first alternative seems to me the nicest but does indeed seem a bit brittle. If, for example, you want to use nixpkgs-18.09 for the system but nixpkgs-unstable for your user then the system The second alternative is very straight forward but will prevent configuring the package set using the Home Manager It is not clear to me how to best solve this. Neither of these two options seem solid enough to me to act as a default. I'll have to think about it 🙂 |
If you're providing a different nixpkgs for each of nixos system config and the user, you would really want to assign to Though not quite the same thing, the notes on the nixpkgs
|
That'd be great. I'm currently struggling at using unstable packages in my nixos-managed home.nix. Setting in didn't work - due to |
|
Same here - I'd like to be able to build my whole system closure, using home-manager as a NixOS module, without having another |
|
I settled on installing all packages from stable and specifying the ones from unstable with let
unstable = import <nixos-unstable> { config = config.nixpkgs.config; };
...
in {
nixpkgs.overlays = [
(pkgself: pkgsuper: {
somePackage = unstable.somePackage;
otherPackage = unstable.otherPackage;
} )
];
...
}@flokli That probably isn't the solution to your problem though. |
|
I understand @arcnmx made some PRs (#993, #992) that were supposed to make it possible to evaluate When I try to build my config with This, in turn, is due to this unfortunate line in the I've tried some of the above tricks, but have been unable to get nix to not evaluate Some salient points of my config: |
|
#1059 solves this issue for users the NixOS module. |
|
I'm using |
You could do something like this:
{ pkgs, lib, ... }:
{
# home-manager config here
}
{ config, pkgs, lib, ... }:
let
dotfiles = with lib; mkMerge [
(import ./dotfiles.nix)
{
someOption = config.services.xserver.dpi;
}
];
in
{
imports = [
<home-manager/nixos>
];
home-manager = {
users = {
user = dotfiles;
};
useGlobalPkgs = true;
useUserPackages = true;
};
} |
Thanks. I could, but I was using that option as an example. I'd hope to be able to reference arbitrary NixOS config options across files, so I don't know if a localized let expression renaming options would be the best tool. I was under the impression that erikarvstedt's PR implemented this, given that he said it solves this issue and the original issue stated
but if someone can confirm this particular use case doesn't work yet, I'd appreciate it. Sorry if I'm misunderstanding anything |
I don't really understand what are you trying to do. Could you provide your config? { config, pkgs, lib, ... }:
{
imports = [
<home-manager/nixos>
];
home-manager = {
users = {
# note: no config here, because it's not system's config but H-M's
user = { pkgs, lib, ... }:
{
someOption = config.services.xserver.dpi;
};
};
};
}
Isn't it only for options under |
Yeah, I actually took the time to look at the PR now, sorry. You're right. In that case, this issue should probably remain open since there's probably still room for improvement with respect to a way to reference global config. I still don't fully understand your example, sorry. When I remove |
|
@hpfr Just bind the NixOS { config, ... }:
{
home-manager.users =
let nixosConfig = config;
in {
yourusername = { config, ... }: {
home.file.sysdpi.text = toString nixosConfig.services.xserver.dpi;
};
};
} |
@rycee Thanks, this works, but only locally. I've been defining some of my own modules that I import within my user config, and referencing |
|
Ok, thanks to rycee's help on IRC, I ended up with this:
{ config, lib, pkgs, ... }:
{
home-manager.users.user = let nixos-config = config;
in { config, lib, pkgs, ... }: {
_module.args.nixos-config = nixos-config;
imports = [ ./path/to/my/home-manager/module.nix ];
some.home-manager.option = nixos-config.some.value;
};
}
{ nixos-config, config, lib, pkgs, ... }:
with lib;
let cfg = config.profiles.polybar;
in {
options.profiles.polybar.enable = mkEnableOption "my polybar configuration";
config = mkIf cfg.enable {
services.polybar = {
enable = true;
config."bar/main".height = if nixos-config.services.xserver.dpi == 192 then 34 else 24;
};
};
}I think leveraging Nix to dynamically define configuration is a great use of home-manager and sets it apart from other dotfile management solutions. Maybe it's worth adding this to the manual? In any case, thanks for the help everyone! |
|
Thank you for your contribution! I marked this issue as stale due to inactivity. If this remains inactive for another 7 days, I will close this issue. Please read the relevant sections below before commenting. If you are the original author of the issue
If you are not the original author of the issue
Memorandum on closing issuesIf you have nothing of substance to add, please refrain from commenting and allow the bot close the issue. Also, don't be afraid to manually close an issue, even if it holds valuable information. Closed issues stay in the system for people to search, read, cross-reference, or even reopen--nothing is lost! Closing obsolete issues is an important way to help maintainers focus their time and effort. |
|
So I believe following nixpkgs' example and creating an equivalent |
|
Apparently there is now I recently stumbled over it, and didn't notice when it got introduced. I assume the same applies to many interacting with this issue. Can we expose this even more prominently? |
This had me tripped up for a while today, was wondering why my overlay wasn't working. Setting |
|
Thank you for your contribution! I marked this issue as stale due to inactivity. If this remains inactive for another 7 days, I will close this issue. Please read the relevant sections below before commenting. If you are the original author of the issue
If you are not the original author of the issue
Memorandum on closing issuesIf you have nothing of substance to add, please refrain from commenting and allow the bot close the issue. Also, don't be afraid to manually close an issue, even if it holds valuable information. Closed issues stay in the system for people to search, read, cross-reference, or even reopen--nothing is lost! Closing obsolete issues is an important way to help maintainers focus their time and effort. |
|
Still relevant. |
|
There doesn't seem to be an equivalent approach when using |
|
@LunNova IIUC, the flake-based Home Manager configuration always use the nixpkgs from the home manager flake input, and one can adjust it by {
inputs.nixpkgs.url = "blablabla";
inputs.home-manager.inputs.nixpkgs.follows = "nixpkgs";
} |
|
@ShamrockLee While that works, you get an uncustomized nixpkgs. If you've already imported it, configured it, and added overlays elsewhere in your flake it's wasteful for home-manager to import it again and not very helpful. I currently use this: |
|
Lines 44 to 47 in 63dccc4 You can override the pkgs argument actually
|
|
Anyway, @LunNova if you could move the discussion to a new issue it would be appreciated given the two problems are different. The original issue is about using the global nixpkgs configuration when using Home Manager as module. The original issue was resolved when the |
The nixpkgs pulled in by home-manager's nixos module may not have access to proper system config options, overlays, or run into weird mismatches when building remotely or with nixops, etc.
Workarounds are easy enough:
But it seems like the module should be doing something like this by default?
The text was updated successfully, but these errors were encountered: