Make self'/self and inputs'/inputs more similar

[Pacman99]

Opened #152 but then I realized that it is probably not a good idea, because it seems self' and inputs' are picky about what they include for some reason.

So I just have a general question and possibly a feature request: Can self' and self and inputs' and inputs be more similar?. It seems only attributes that flake-parts supports are "de-systemized" in inputs', but why not just pick out any attribute thats system spaced and include all the original attributes in the flake. Then maybe the self' and self distinction won't even be necessary. Something like how de-systemizing is done here could be goo https://github.com/divnix/nosys/blob/master/desys.nix.

Maybe I'm misunderstanding flake-parts philosophy or architecture, but it seems unnecessary to have such a big distinction between concepts that are so similar.

[roberth]

philosophy or architecture

It is meant to be quite conservative and unopinionated, while extensible. This way, flake-parts has a chance of gluing together all flake logic, instead of a niche that is ok with many assumptions.

As a real world example, by not merging self' into self, we can have attributes that are meaningful in both contexts:

• self.nixosConfigurations: a precise mapping of how each machine is configured
• self'.nixosConfigurations: all the ways you could cross compile the configuration of each machine

Admittedly this may be a niche interpretation of nixosConfigurations, as it reinterprets the system attribute as the buildPlatform instead of the more usual hostPlatform, which is implied by nix run, nix develop, etc.
(I guess the role of system is about as arbitrary as the values defined for it; appears rigid, but is a bit arbitrary. All I've teased out is "whatever the CLI uses it for." - and I'm on the team...)

On the flip side, there's a lot you can actually modify from the comfort of your own modules. For instance, you could merge a very broad definition into perInput. I think it respects priorities, so you could probably add mapAttrs (k: mkDefault) and achieve the goal of merging self into self'.

I would recommend not to rely on that if you're going to write reusable modules for a large audience, but if it helps your own flakes, then why not?