My mantra has been to avoid "getting bored" and inventing DSLs for the longest time. I initially sought to use Nickel-lang, but it was missing some features that would make it an ideal candidate for this. I started writing my own (you may find this in the history) before realizing "WTF are you doing writing another shitty DSL?" I have subsequently decided that shell scripts (or anything you can shebang) are good enough, i.e. pkgbuild inspiration.
I also plan to avoid making a derivation the source of reproducibility. Instead, a lockfile will offer that. This should alleviate the issue whereby updating the like of glibc cascades into an entire rebuild.
Any *OS and home-manager would need to bring in a configuration language. I think Cue really makes the most sense, but that's still a long way off.
Nice to see you used JS instead of yet another DSL :)
I suggest the post author and you look into nu as the package build language. It's uniquely suited for this task, being a cross-platform shell[1] with real programming language features, data types, and using built-in uutils instead of relying on platform-dependent coreutils. It also limits mutability[2], favoring a more functional than imperative approach, which would at least theoretically help with reproducibility. A guy from Determinate Systems recently made an experiment on integrating nushell to nix and the results were positive. Take a look: https://determinate.systems/posts/nuenv/
Nushell has definitely been on my radar for a while! but I missed DetSys was playing around with it, I'll have to give that a look
One neat thing about Brioche is that Bash isn't really baked into it the same way as the Nix ecosystem. In a lot of the docs and examples, I used the `std.runBash` Brioche function for running scripts, but that's a fairly simple 11-line function[^1]. I wanted to make it just as easy to add `runZsh`, `runFish`, `runNushell`, etc. functions that work just as well as Bash (and they could either be put in the std library or in their own packages). So hopefully, there will be a Brioche `runNushell` function in the near future :)
ooh, porkg looks pretty interesting, will definitely keep an eye on the project!
Definitely agreed about the lockfile ideas! I went with a fairly similar design, although I haven't really escaped the "rebuild the world" situation yet and I've rebuilt a _lot_ of copies of gcc from source by now! (that's also partially because I set up the packages repo as a workspace[1], which I felt was easier to iterate on in the early days... I might eventually split each package into their own projects or separate repos so they can keep lockfiles independent of each other)
and yeah, I definitely felt the temptation to write my own DSL but I stayed strong! I just knew that it'd be a huge uphill battle, especially because I wanted to provide good editor support (IMO implementing a language is (relatively) easy, but implementing a language with good error messages and LSP support is crazy hard)
My mantra has been to avoid "getting bored" and inventing DSLs for the longest time. I initially sought to use Nickel-lang, but it was missing some features that would make it an ideal candidate for this. I started writing my own (you may find this in the history) before realizing "WTF are you doing writing another shitty DSL?" I have subsequently decided that shell scripts (or anything you can shebang) are good enough, i.e. pkgbuild inspiration.
I also plan to avoid making a derivation the source of reproducibility. Instead, a lockfile will offer that. This should alleviate the issue whereby updating the like of glibc cascades into an entire rebuild.
Any *OS and home-manager would need to bring in a configuration language. I think Cue really makes the most sense, but that's still a long way off.
Nice to see you used JS instead of yet another DSL :)