Discussion
derivation gnu.hello-2.12.3 {
source {
derivation "/sickos/<hash>-hello-2.12.3.tar.gz.drv"
hash algo=blake3 "..."
}
build-system shell #"""..."""#
output out {
path "/sickos/<hash>-hello-2.12.3"
hash algo=blake3 "..."
}
derivation gnu.hello-2.12.3-source {
source {
shell {
command "/usr/bin/curl" ...
}
hash algo="blake3" "..."
}
build-system identity
output out {
path "/sickos/<hash>-hello-2.12.3.tar.gz"
hash algo=blake3 "..."
}
}
I think this can work.
One of the questions I have is: what information should a derivation contain? What do I need to build it? And how do I serialize that in a sane way?
Previously, when I was doing KDL config + Fennel extensions, it was all nicely KDL, and I could conveniently encode the builder + its "arguments" as a KdlDocument.
That's probably not the right approach when using Fennel for the config language.
I think I'm overengineering this again, because I keep thinking about bootstrapping, and reproducibility from ~zero. Those are nice, but... probably not important right now.
All I need is to have a derivation, and some builders that can produce the desired output. For simplicity's sake, I'd even implement a fuck-provided builder that requires no external tools, that can copy some declared files to the store. But how do I encode that in the derivation?
Maybe I'd continue using KDL. I do need a serialization format for derivations, and Fennel's not it: I don't want a programming language in the derivations! It's 100% data, and KDL feels like a better fit than a Fennel table.
In which case, the internal builder could also be parameterized via KDL. But that means all other builders would receive their parameters that way too...
On second thought, that's not a bad thing.
Install bonfire.cafe
Get the full app experience
Questions about laziness, macros, namespacing, parameters, and suchlike. Yes, very vague, but the questions themselves are more of a feeling in my head than questions I can actually describe or ask.
It's complicated.