For example, compose2nix lets you build nixos configuration for containers defined in a docker compose compose.yml. But this step happens offline. You have to first ad hoc generate the config from the compose.yml and then use that generated output in your config.
It seems obvious to me that the best user experience would be to write a flake/module that let's you just point to a compose file directly in your config. On rebuild, it would parse the compose file and build the appropriate config.
But I've not really seen that. These projects that convert from one package mamagement scheme or config file to another (xxx2nix projects) work using this preprocessing step. More examples include pip2nix and cargo2nix.
Given how common this pattern is, I suspect there is something preventing generating at rebuild time from being feasible, or at least easy. Does anyone have ideas for why this is? Thanks.
@rutrum isn't it because of the fear of import from derivation?
@6d03
@rutrum more it's performance impact
Could you say a bit more about that? I was actually wondering about the exact same thing as OPs question. Is the performance so bad that it doesn't even make sense to consider this as an option? Idk, just like OP I feel like it's such an obvious use case that it really should be a thing.
@QuizzaciousOtter
You can then no longer split pure evaluation and build as you need to build an undefined amount of things to finish the first evaluation. This is especially worse for Hydra, for nixos systems it usually works. Especially when bootstrapping is involved this can make the initial eval take almost days.
Thanks for the answer! This sounds terryfing indeed. By bootstrapping, do you mean like an initial mass build without anything in store?