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.
Nix builds go through 2 phases, first downloading the dependencies into the nix store (which can also go through a nix build) and then executing the builder with access to the nix store but without network access. This is done for purity because network access can lead to non-reproducible builds.
Most languages and tools are complex but can output URLs to their depdencies or download them, but that cannot happen during the build (no network access). So, either a tool predownloads stuff and they can be put into the nix store by the "simple" nix derivation, or the tool (pip, docker compose, cargo,...) has to be rewritten either partially or completely in nix. The latter is much harder and in most cases would just lead to repeating the work. Nix may be a functional language but it's missing important language features like static typing.
Anti Commercial-AI license