4 ms·

I'm also exploring a post-Nix package manager, wip: https://github.com/porkg/porkg https://github.com/porkg/porkg My mantra has been to avoid "getting bored" a

I'm also exploring a post-Nix package manager, wip: https://github.com/porkg/porkg 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 2y ago
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/ https://determinate.systems/posts/nuenv/ 1: https://www.nushell.sh/ https://www.nushell.sh/ 2: https://www.nushell.sh/book/thinking_in_nu.html#variables-are-immutable https://www.nushell.sh/book/thinking_in_nu.html#variables-ar...
- kylewlacy 2y ago
  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/9fd51090a56cf83f4aa9c5002b78f2b2054ad3ad/packages/std/extra/run_bash.bri#L37-L47 https://github.com/brioche-dev/brioche-packages/blob/9fd5109...
kylewlacy 2y ago
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/ https://brioche.dev/docs/core-concepts/workspaces/
chubot 2y ago
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 https://www.oilshell.org/release/0.22.0/doc/hay.html Discussion - https://lobste.rs/s/phqsxk/hay_ain_t_yaml_custom_languages_for_unix 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)

Aerbil313 2y ago

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/ https://determinate.systems/posts/nuenv/ 1: https://www.nushell.sh/ https://www.nushell.sh/ 2: https://www.nushell.sh/book/thinking_in_nu.html#variables-are-immutable https://www.nushell.sh/book/thinking_in_nu.html#variables-ar...

kylewlacy 2y ago
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/9fd51090a56cf83f4aa9c5002b78f2b2054ad3ad/packages/std/extra/run_bash.bri#L37-L47 https://github.com/brioche-dev/brioche-packages/blob/9fd5109...

kylewlacy 2y ago

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/ https://brioche.dev/docs/core-concepts/workspaces/

chubot 2y ago

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 https://www.oilshell.org/release/0.22.0/doc/hay.html Discussion - https://lobste.rs/s/phqsxk/hay_ain_t_yaml_custom_languages_for_unix 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)