Replace 'configurationsXyz' and 'modulesXyz' with 'configurations.xyz' and 'modules.xyz'

[gytis-ivaskevicius]

Simply put - the current approach is just not scalable, we got projects defining custom modules/configurations which are being recognized as 'unknown' due to the lack of a type system.
Some peeps suggest implementing nixpkgs options system or type system via JSON spec but I think the best solution here is to just remove the need for a type system in this case entirely.

Expected properties rename:
nixosConfigurations.hostname = {...} to configurations.nixos.hostname = {...}, so schema would be: configurations.<name>.<hostname> = {...}
nixosModules.moduleName = {...} to modules.nixos.moduleName = {...}, so schema would be: modules.<name>.<moduleName> = {...}
(Similar idea to REST naming convention and existing system-specific properties)

Also, may I add that there is one annoyance current nix flake check implementation:

nix/src/nix/flake.cc

Line 421 in 895dfc6

auto vToplevel = findAlongAttrPath(*state, "config.system.build.toplevel", bindings, v).first;

Alias in nixpkgs should be added so we could replace this line with something like this:
auto vToplevel = findAlongAttrPath(*state, "config.drv", bindings, v).first;

[edolstra]

It's not clear to me what the advantage of this proposal is. What's the usefulness of having a semantics-free configurations output type?

[gytis-ivaskevicius]

This allows the community to define its own module groups. Here are a few examples:

• nix-darwin users would use modules.darwin and confiugurations.darwin (currently they use darwinModules and darwinConfigurations attributes, which are 'unknown' and not checked by nix flake check)
• home-manager - same idea as nix-darwin
• Everyday nixers could make use out of such namespaces as well, for example having groups such as: modules.{server,desktop,cli,development,etc}. In fact I do have something similar implemented here https://github.com/gytis-ivaskevicius/nixfiles/blob/master/suites.nix (lines: 3, 19, 32)

[gytis-ivaskevicius]

Oh, and just to be clear

What's the usefulness of having a semantics-free

It is not semantics-free. Current design is nixosModules = <module>, this would change definition to modules.<name> = <module>

[bew]

It is not semantics-free. Current design is nixosModules = <module>, this would change definition to modules.<name> = <module>

But there may be other kinds of modules, nixos ones are not the only ones.
(Same for configuration)

[gytis-ivaskevicius]

But there may be other kinds of modules, nixos ones are not the only ones.

Yeah, which is why I am suggesting to make flakes schema more flexible, so it could accommodate nix-darwin/home-manager/etc modules as well.

[Pacman99]

Overall a good idea 👍 I think this would cleanup flake's relationship with configuration systems.

Largest question for me is whether nix flake check knows how to "check" home-manager/darwin systems? And if it doesn't I presume it would just check configurations.nixos.*.

Also to be clear it would be modules.<config-system-name>.<name> = <module> right?

Although, I could see modules actually following a pattern similar to packages here where a module can claim to support different config systems and it would actually be modules.<name>.<config-system-name> = <module>. So if modules.agenix has a nixos and darwin attribute, it can support bot those config systems.

[gytis-ivaskevicius]

Largest question for me is whether nix flake check knows how to "check" home-manager/darwin systems? And if it doesn't I presume it would just check configurations.nixos.*.

The answer is simple: Nope. One of the checks is the derivation path itself, there are a few options:

1. Create some sort of standard like instead of searching for config.something.toplevel just have a standard alias something along the lines of config.drv
2. Check for derivation only in case of NixOS configs, free pass for everything else 👎
3. Hardcode home manager/darwin projects drv paths into nix 👎

As for the last part - I did not quite get it. Assuming modules are identical I would expect something along the lines of this:

{self}:{
    modules.nixos.abc = import ./xyz.nix;
    modules.darwin = self.modules.nixos;
    
    # As of right now common approach is: https://github.com/gytis-ivaskevicius/flake-utils-plus/pull/111/files
    nixosModules = {abc = import ./xyz.nix;};
    darwinModules = self.nixosModules; # unknown properly
}

[marksisson]

I posted a copy of my flake (#6723) using nixosConfigurations attribute to contain home-manager and darwin configurations - this flake does not have errors when running nix flake check, but the extra complexity highlights the fact that the "configurations" abstraction could be better.

[roberth]

With a solution like https://github.com/hercules-ci/flake-parts you could remove the hardcoded schema checking in Nix and let the nixpkgs repo define nixosConfigurations, let nix-darwin define darwinConfigurations, etc. I'll be happy to remove the nixos* attributes from flake-parts.

I'm still surprised how much Nix is hardcoding ecosystem stuff that it has no business knowing about. It's as if we've forgotten that the nix implementation can't be pinned by expressions or lock files. Good thing flakes are experimental so this stuff can still be removed.

[DavHau]

I think getting this change in before the stable release of flakes is important.
More and more projects are evolving in the ecosystem that export modules, but there is no suitable output in the current schema.

Examples for these projects:

• flake.parts
• jupyenv (previously jupyterWith)
• drv-parts

And of course there are the well known:

• home-manager
• nix-darwin

In my opinion, the most reasonable schema would to be a 3 levels nested attrset, like:
modules.<config-system-name>.<name> = <module>.

@gytis-ivaskevicius Reading the OP it's not quite clear if you are suggesting a 2-levels or 3-levels nested attrset. Maybe you could edit the OP to make that more clear.

[gytis-ivaskevicius]

Updated