[zamalek]

I'm also exploring a post-Nix package manager, wip: https://github.com/porkg/porkg

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 :)

[Aerbil313]

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/

1: https://www.nushell.sh/

2: https://www.nushell.sh/book/thinking_in_nu.html#variables-ar...

[kylewlacy]

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 :)

[^1]: https://github.com/brioche-dev/brioche-packages/blob/9fd5109...

[chubot]

I have subsequently decided that shell scripts (or anything you can shebang) are good enough, i.e. pkgbuild inspiration.

If you run out of steam with shell, keep Hay in mind -- which is part of Oils.

It upgrades shell with declarative data, like YAML but not YAML syntax :)

https://www.oilshell.org/release/0.22.0/doc/hay.html

Discussion - https://lobste.rs/s/phqsxk/hay_ain_t_yaml_custom_languages_f...

It's not set in stone yet -- I'm planning an overhaul based on some feedback, so I welcome any more (e.g. on Github or Zulip)

[kylewlacy]

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)

[^1]: https://brioche.dev/docs/core-concepts/workspaces/