[flakes] Where do cross compiled packages go?

[roberth]

Is your feature request related to a problem? Please describe.

It's unclear where cross compiled packages should go.
The docs talk about system as if there is only one. With cross we have two or three.

Describe the solution you'd like
Describe alternatives you've considered

I don't care much about the convention chosen. Pretending that cross compiled packages have one system seems like a bad idea.

• flake system == build system: packages can't be used properly as a dependency. Who knows what kind of binaries are in there.
• flake system == host system: packages can't be filtered by build system without evaluating them to some degree

The latter seems like the lesser evil, but it's still awful. I think this should be done differently altogether. This would all be much more natural if flakes were functions from system and optional buildSystem to outputs. I know that this doesn't work with the current caching approach, which is too tightly coupled to the current flakes design. Did you consider an builtins.importApplyCached : path -> json -> value? It'd behave like f: a: import f a but with a persistent evaluation cache. It seems that current flakes design can be cached with it (and some Nixlang glue), but also allow dynamic uses where not all arguments are statically known and enumerated as attrs.

[nixos-discourse]

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/how-do-i-cross-compile-a-flake/12062/5

[nixos-discourse]

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/flakes-nix3-0-issues/15626/10

[roberth]

It seems that the ${system} attributes are usually about the runtime system.

NixOS/nixpkgs#160061 makes the Nixpkgs configurable for cross and other configs (and needs review).