Help with a lack of logic

[filipeltsilva]

Hi!

I'm trying to migrate my configs to a dendritic pattern, but I'm having some troubles.

The way it is currently, I'm having the error "The option 'flake' does not exist" in the /modules/nixos/hosts/sandbox/default.nix file.

I want to set up the modules calling them without importing the files, like many of you get it, but I didn't find the way yet. I know my modules hasn't a pattern yet.

Help me, please! I'm feeling I'm close to solve this.

The repo's link is here!

Thanks!

[vic]

Looks like you are missing this flake-parts installation step, which enables the flake.modules option.

[filipeltsilva]

Looks like you are missing this flake-parts installation step, which enables the flake.modules option.

I enabled them here.

[vic]

"You are absolutely Right!"(tm)

Your flake.nix looks fine, and it should be picking that file of yours and flake.modules option available. Hm, I'm wondering why that is happening.

Just a heads-up, in sandbox/default.nix you have

flake.modules.nixos = {
    hosts.sandbox = {
      networking = ...
# existing code

I'm not sure about what you are trying to achieve here, but I am almost sure that should be flake.modules.nixos.sandbox, the structure for flake modules is flake.modules.<class>.<name> and under <name> all nixos configuration, and sandbox is not a NixOS option unless you have something that enables it.

This is not related to your flake is not an option, but perhaps the error is terribly wrong.

[filipeltsilva]

My goal is set up a host as a module, like I saw in many configs, and call it through the easy-hosts library or similar way. I want the host machine as a module and import another configuration modules inside it without fall in infinite recursion error.

[vic]

I'm not familiar with easy-hosts, if you are trying to use easyhost, perhaps you should do

(again, don't trust me, I know nothing of easy-hosts)

Assuming sandbox is the name of the nixos module you are trying to define:

# this is a flake-parts module.
{
  easyhosts.hosts.sandbox.modules = [
    # nixos modules according to the docs, please follow the docs not me.
  ];
}

If you are using plain flake-parts, then

{
  flake.modules.nixos.sandbox = {
    # this is a NixOS module, place configurations like networking... here.
  };

  # instead of what you have currently:
  # flake.modules.nixos.hosts.sandbox = 
  # In your code, that `hosts` is the name of the nixos module, and `sandbox` is a nixos option
  # and that IS an error. 
}

[vic]

were you able to fix the error ? did the docs help / what was causing it ?

[filipeltsilva]

I renamed the modules according the dendritic pattern because I had overdoing in these specifications. I had to use the nixos class for modules I didn't want (/modules/core) because it doesn't accepting custom class name, but I will fix it later when I will set the aspects.

However, I'm having issues with attribute pkgs missing yet.

[filipeltsilva]

I think the source of the error above is in the /hosts/sandbox/hardware-configuration.nix. If I remove the flake.modules implementation, I get the infinite recursion error.

[filipeltsilva]

I'm passing pkgs as a parameter when I need it, but the modules aren't reckonizing. If I remove all my pkgs parameters in a host implementation I don' t have any errors.

[vic]

Access pkgs like this:

flake.modules.nixos.foo = { pkgs, ... }: {
  
}

[filipeltsilva]

Access pkgs like this:

flake.modules.nixos.foo = { pkgs, ... }: {
  
}

I already tried it but it didn't work. But I removed the pkgs call in the host definition file and retried your suggestion. And it worked! XD

Why do I need to change the pkgs scope this way?

Now I will adjust the modules structure to not install specific packages by host like I was doing before.

Thank you for the support and the patience. Functional programming isn't my strong spot and my English is not very fluent yet to easily understand the flake-parts concepts.

Best regards from Brazil!

[vic]

Regards from Mexico! :) My english is pretty bad, so no worries, we should all be talking Esperanto. Anyways, I'm glad you are progressing in your journey and it works, I was looking at your latest diff:

On the left side, this was the correct structure to use flake.modules

# This top-level module is a `flake` module itself (because we are using flake-parts, right?)
# so it is NOT a NixOS module, you can access lib, config, but they are NOT the same as
# the config available in the core_host.
# 
# The top level config is at the flakes level, it allows you to access for example: config.flake.modules.nixos.bar
# This top level flakes module has access to inputs, but not to pkgs
{ lib, config, inputs, ... }: 
{
  # this is a nixos module named `core_host`, any nixos module has `pkgs` arg already.
  # here, the nixos module has access to pkgs, and its config param is TOTALLY DIFFERENT
  # from the top level config. the config here access NixOS level settings.
  flake.modules.nixos.core_host = { pkgs, config, ... }: {
    
  }
}

Tried to add some comments because I see you tried to access pkgs from top-level flakes module. and the flake has no pkgs. They are available on nixos modules.

Now, other thing regarding your diff:

Dendritic (read our docs) is about using different configuration classes in a single file. A config class is nixos, homeManager, darwin and many others. From your code, I see you are mostly using nixos only.

{ 
  # this:
  flake.nixosModules.foo = { pkgs, ... }: { };
  # is equivallent to this:
  flake.modules.nixos.foo = { pkgs, ... }: { };
}

The only difference will come when you try to combine more than one nix class, like nixos and homeManager.

Compare:

# this flake module configures `foo` across `nixos` and also `homeManager` types of configurations.
# this is pure dendritic style.
{ 
  flake.modules.nixos.foo = { pkgs, ... }: { };
  flake.modules.homeManager.foo = { pkgs, ... }: { };
}

With this:

# I don't think flake.homeManagerModules even exists
{ 
  flake.nixosModules.foo = { pkgs, ... }: { };
  flake.homeManagerModules.foo = { pkgs, ... }: { };
}

The reason is that there are lots and lots of different nix classes, like for configuring vim: nixvim, or nixos on android: nixdroid. so it is impossible for flake-parts to have flake.<class>Modules.foo for each of them, instead you use flake.modules.<class>.foo where class is dynamic, and need not to be supported by flake-parts beforehand.