Nix has abstractions for about any built scenario as long as the output generates a store path.
In the context of driving whole repositories and developmemt emvironment with nix (not only the build), I wonder:
What would be a good enough abstraction to modify the repo’s source (in stead/addition of the nix store)?
Use case:
Code generators, such as go makes heavy use of. But also a quick rendering of markdown filw from sources in a nix job.
nix just runs what you specify, and it can create arbitrary stuff, as long as the output goes to the store.
So a derivation that takes your source, augments it with auxiliary files to create a store path entry, or compiled sources even, which then can be used as the source for another derivation is not only possible, but quite common.
Just take a look at all the “wrapped”/“unwrapped” package pairs.
@NobbZ Thanks for the pointers! I think there is a misunderstanding involved, though:
To be clear: the target of the generated sources is not another derivation but a git commit.
I kind of get a sense, that there is no abstraction in nix for this use case. I can always do a thin bash wrapper of course, but that would prohibit semantics such as nix build .#jobs.my-code-generator (without being wrapped in a bash script that is allowed to modify paths outside of the nix store).
Or am I misunderstanding something? 