You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.system
== buildsystem
: packages can't be used properly as a dependency. Who knows what kind of binaries are in there.system
== hostsystem
: packages can't be filtered by buildsystem
without evaluating them to some degreeThe 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 optionalbuildSystem
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 anbuiltins.importApplyCached : path -> json -> value
? It'd behave likef: 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.The text was updated successfully, but these errors were encountered: