20 Jul 2025 |
n4ch723hr3r | { name, config, ... }: i dont think config exists in that scope, right? | 14:52:46 |
n4ch723hr3r | you probably need to do fooConfs.${name}... | 14:53:26 |
n4ch723hr3r | and afaik fooConfs is often named cfg in nix modules | 14:53:52 |
x10an14 | Nah, sorry, there's something I'm messing up/not getting 😅 See this paste: https://paste.sr.ht/~x10an14/653ed23dd63ba7166d4da89b315c9cce3c4f92c8 And see the comment. Here's the error when I try to nix eval .#modules.x10.device-configs :
x10an14@home-desktop ❯ : nix eval .#modules.x10.device-configs
warning: Git tree '/home/x10an14/Documents/sr.ht/nix-parts-conf' is dirty
{ "x10an14@home-desktop" = { homeManager = { entryPoint = «error: attribute 'username' missing»; homeDirectory = «error: attribute 'system' missing»; toplevelBuild = «error: The option `flake.modules.x10.device-configs."x10an14@home-desktop".homeManager.toplevelBuild' was accessed but has no value defined. Try setting the option.»; }; hostname = "home-desktop"; system = "x86_64-linux"; username = "x10an14"; }; "x10an14@nav-x10an14-t14" = { homeManager = { entryPoint = «error: attribute 'username' missing»; homeDirectory = «error: attribute 'system' missing»; toplevelBuild = «error: The option `flake.modules.x10.device-configs."x10an14@nav-x10an14-t14".homeManager.toplevelBuild' was accessed but has no value defined. Try setting the option.»; }; hostname = "nav-x10an14-t14"; system = "x86_64-linux"; username = "x10an14"; }; }
See the errors reporting missing attributes?
| 15:03:15 |
n4ch723hr3r | you can also do nix repl then enter :lf . | 15:04:06 |
x10an14 | I know that, but again, I'm asking here because I don't know what I should be exploring. There's something missing in my mental model, and I'm here asking for a nudge in the right direction^^
Answering your suggestion on using the nix repl directly, how can I in the repl explore what the config attribute w/the comments look like? I only know how to explore evaluated configs/outputs in the repl
| 15:06:31 |
n4ch723hr3r | {
name,
username, # <- I want access to these, that live under `config.flake.modules.x10.device-configs.<a device>,`
hostname, # <- I want access to these, that live under `config.flake.modules.x10.device-configs.<a device>,`
system, # <- I want access to these, that live under `config.flake.modules.x10.device-configs.<a device>,`
...
}:
let
ihnerit (config.flake.modules.x10.device-config.${name}) username;
in
{
options.homeManager = {
| 15:06:44 |
n4ch723hr3r | * {
name,
...
}:
let
ihnerit (config.flake.modules.x10.device-config.${name}) username;
in
{
options.homeManager = {
| 15:06:54 |
n4ch723hr3r | how about that? | 15:07:01 |
n4ch723hr3r | * {
name,
...
}:
let
inherit (config.flake.modules.x10.device-config.${name}) username;
in
{
options.homeManager = {
| 15:07:07 |
x10an14 | Gotcha. Just managed to put 2+2 together with your previous mention of fooConf.${name} . I got infinite recursion error | 15:09:37 |
n4ch723hr3r | yeah i hope that makes sense why you got infinite recursion error | 15:10:34 |
n4ch723hr3r | * yeah i hope that it makes sense why you got infinite recursion error | 15:10:45 |
x10an14 | I got it to work with lots of help from @mightyiam:matrix.org (thanks)! =) | 17:11:02 |
n4ch723hr3r | nice what did you do? | 22:12:49 |
21 Jul 2025 |
x10an14 | Something I'd already tried earlier but discarded due to an unrelated error (that I thought told me I could not do things this way):
{
type =
with lib.types;
attrsOf (
submodule (
nixosConfig:
let
cfg = nixosConfig.config.nixos;
inherit (nixosConfig.config) hostname username system;
in
{
options.nixos = builtins.break {
entryPoint = lib.mkOption {
type = lib.types.path;
default = "${repoRoot}/nixos/${username}_at_${hostname}";
};
toplevelBuild = lib.mkOption {
type = lib.types.raw;
readOnly = true;
};
};
config.nixos.toplevelBuild = lib.mkIf (builtins.pathExists cfg.entryPoint) (
inputs.nixpkgs.lib.nixosSystem {
modules = [
{
nixpkgs.hostPlatform = { inherit system; };
}
(import cfg.entryPoint (inputs // { inherit repoRoot; }))
"${repoRoot}/x10/options/unfree-packages.nix"
inputs.nur.modules.nixos.default
];
specialArgs = {
inherit inputs hostname repoRoot;
};
}
);
}
)
);
}
So yeah, the inner config variable of the extending submodule contains the submodule's "sibling" option values.
| 07:14:28 |
nbp | x10an14: taking the discussion from the beginning …
If you want to declare options specific to one instance, you can do it as follow:
{ lib, ... }@toplevel:
{
config.flake.modules.foo.<fooInstance> = {config, ...}@submoduleInstance: {
options.home-manager = lib.mkOption { ... };
config.home-manager = ...;
}
}
If you want to make the home-manager option available to all instances, then your initial example is almost there, you have to redefine the foo option with the submodule that you want to add. Submodule option declarations are merged, see fileSystems option as an example, which is declared in multiple modules.
| 09:36:22 |
nbp | If you want your option to define home-manager.<user> from foo.<user> , unfortunately there is no simple shortcut that exists today, you will have to fallback to the nix language / Nixpkgs library to map the attributes of one into the other. | 09:39:25 |
x10an14 | nbp: Thanks! =D
I got it to work, as described in the previous 2x messages of mine =) This is how I did it: https://git.sr.ht/~x10an14/nix-parts-conf/tree/main/item/device-configs/home-manager.nix
Any feedback/suggestions welcome! PS: I urge those who've got feedback/suggestions to consider whether it's too niche for this channel/is maybe better suited for a DM =)
| 10:29:35 |
nbp | x10an14: This is the right channel. Thanks for the link, I was not aware of the pipe operator. | 12:03:29 |
x10an14 | Aight, and yw =) | 12:07:17 |
25 Jul 2025 |
| hsjobeki joined the room. | 12:11:00 |
31 Jul 2025 |
| unwary joined the room. | 00:25:28 |
unwary | This might be the wrong chat, but I'm trying to understand how to package something like a .desktop file so that a module I write will be included in start menus and such. Right now, enabling my module gets me the executable available on the command line, but as it's a GUI program, that's suboptimal. | 00:26:59 |
Shahar "Dawn" Or | There's plenty of examples in Nixpkgs. Did you find some? | 06:42:08 |
Shahar "Dawn" Or | And yes, this isn't quite the correct room. | 06:42:25 |
| sammy (It/Its) joined the room. | 09:35:10 |
| Sammy (It/Its) left the room. | 10:02:52 |
unwary | I did not, or did not detect it. I seemed to examine modules that used various build-wrapping tools that I presumed handled that as part of the build. | 23:53:39 |
1 Aug 2025 |
Shahar "Dawn" Or | Sorry for not being clear. It's not in a NixOS module typically, but in the package for some piece of software. And might not be obvious. The part of this that is in the NixOS module is that the package of the software ends up in environment.systemPackages and includes the .desktop file. | 06:32:42 |