Packaging GNU hello is also a focus of examples in the NixPkgs manual[0]. With this Guix tutorial, there is now a litte more pairity between two great tools.
Speaking of parity, while the Guix project may have some catching up to do in general, I think their documentation has been superior to Nix for a while.
I always appreciate more documentation when it comes to Nix and Guix. Being still somewhat new to Nix and Guix I found myself looking up other people's declarations on Github because the official documentation was lacking.
I like the idea a lot, although the kind of people who don't like shell scripts for init would likely flip completely out at packages using guile lisp rather than some obscure DSL, and then parenthesis-ophobes are going to react very poorly to the libgit2 extended example ending in four closing parenthesis. A little diversity in thought might be a good thing of course.
An init system written entirely in Guile LISP is interesting to think about. I'm old enough to (barely) remember the 80s lisp machines and since all modern CS/IT progress is re-implementing stuff from four decades ago, we're about due for something like linux ported from C to clojure or another lisp with a new init and the guix packaging system written in guile-scheme-lisp. The idea of an OS written to run on a JVM instead of virtualization like vmware is intriguing. I can come up with enough bright ideas in five minutes to keep me busy for fifty years, so this daydreaming is all very unlikely to happen.
> the kind of people who don't like shell scripts for init would likely flip completely out at packages using guile lisp rather than some obscure DSL
Do you mean people used to systemd specifically or does this also include runit, s6, etc.?
> parenthesis-ophobes are going to react very poorly to the libgit2 extended example ending in four closing parentheses
Though, of course, for humans reading Lisp, the trick is not to focus on the parentheses too much, but use the indentation. And then use the parentheses as a sort of double-sanity check as you move your editor's point/cursor across them and see the other member of the pair light up (assuming a sane lisp editor/editor configuration).
The funny thing is that a DSL looks aesthetically pleasing but is more often than not a nightmare to work with.
Lisp itself is a DSL, it's completely unconstrained by common syntactical conventions (whitespace, block scopes, etc.) and the worst anyone can take away from that setup is that it requires typing ')' too much. Yet there are so many tools invented entirely to manipulate Lisp code so you don't need to rewrite editor plugins and what-not to get fresh syntax highlighting and completion for your brand new language.
Because it's also a programming language, it already supports functions and other constructs for abstraction and code reuse, should you need them for larger scripts with lots of boilerplate.
But tend to reject it and the already done work because of the aesthetics, and then we're going into the GitHub repos for things like Helm, Kubernetes, Terraform, etc. because the custom YAML/JSON-esque templating setup misses vital features and we're having to re-learn the same stuff over and over again.
> parenthesis-ophobes are going to react very poorly to the libgit2 extended example ending in four closing parenthesis
I think parenthesis-phobia is a red herring. The delimiter bytes in s-expressions denote structure, and most s-expression users are happy to render them as parentheses glyphs. Those who aren't are welcome to use one of the myriad preprocessors/renderers which display this structure in other ways, e.g.
Another Guile component is mcron[1] which allows cron jobs to be scheduled using Lispy syntax as well. I have, for instance:
;; fetch mail via isync/mbsync for mu/mu4e every 5 minutes
(job '(next-minute (range 0 60 5)) "/home/$USER/.guix-profile/bin/mbsync -a")
;; run backup every hour
(job '(next-hour (range 0 23 1)) "/home/$USER/.local/bin/borg-backup.sh")
My main problem with guix, and nix, and debs (the 3 i have tried is they are great for software wrapped using automake/autoconf, but I can never figure out how to package things using a custom build system.
It's certainly doable. I contributed Envoy to Nixpkgs (built with bazel) and developed the current incarnation of the RubyGems/Bundler build infrastructure.
Guix and Nix just run scripts. I've less experience with Guix, but in Nix you can just run a bash script which stores the build products in a path given as `$out`. For example, the following is a perfectly valid Nix package, if we replaced the nonsense names and commands:
For example, I've never written any Go, but I was able to package some Go programs by copy-pasting their install instructions into the above template and putting the relevant build tools into `buildInputs`: https://github.com/Warbo/warbo-packages/blob/master/packages...
In contrast, the automake/autoconf support is actually a very complicated tower of helper scripts, override hooks, etc. which is built up on top of the system's built in support for running bash scripts (actually it runs whatever we call `builder` with whatever we call `args`; `runCommand` sets the `builder` to be bash and the `args` to be a file containing our script).
I recently realized that Macports package definition files, Portfiles [1], are actually just TCL. It looks declarative, but that's just because they defined the functions well (and that's how TCL syntax works)
And "Portgroups" are effectively libraries for the packaging system, so that they can easily interface with GitHub, CMake, gobject_introspection, etc...
It's neat how similar this looks to a Bitbake recipe (used by the Yocto Linux project), except that those are written in a DSL that's half Python and half shell-script.
Recently I have gotten very interested in Guix, after 16 years of only Debian. Guix keeps surprising me, most recently its container system. This page is exactly what I was looking for to get started with my own packages.
17 comments
[ 3.3 ms ] story [ 59.2 ms ] thread[0] https://nixos.org/nixpkgs/manual/
An init system written entirely in Guile LISP is interesting to think about. I'm old enough to (barely) remember the 80s lisp machines and since all modern CS/IT progress is re-implementing stuff from four decades ago, we're about due for something like linux ported from C to clojure or another lisp with a new init and the guix packaging system written in guile-scheme-lisp. The idea of an OS written to run on a JVM instead of virtualization like vmware is intriguing. I can come up with enough bright ideas in five minutes to keep me busy for fifty years, so this daydreaming is all very unlikely to happen.
Do you mean people used to systemd specifically or does this also include runit, s6, etc.?
> parenthesis-ophobes are going to react very poorly to the libgit2 extended example ending in four closing parentheses
Though, of course, for humans reading Lisp, the trick is not to focus on the parentheses too much, but use the indentation. And then use the parentheses as a sort of double-sanity check as you move your editor's point/cursor across them and see the other member of the pair light up (assuming a sane lisp editor/editor configuration).
(And maybe: parenthephobes?)
https://www.gnu.org/software/shepherd/
Lisp itself is a DSL, it's completely unconstrained by common syntactical conventions (whitespace, block scopes, etc.) and the worst anyone can take away from that setup is that it requires typing ')' too much. Yet there are so many tools invented entirely to manipulate Lisp code so you don't need to rewrite editor plugins and what-not to get fresh syntax highlighting and completion for your brand new language.
Because it's also a programming language, it already supports functions and other constructs for abstraction and code reuse, should you need them for larger scripts with lots of boilerplate.
But tend to reject it and the already done work because of the aesthetics, and then we're going into the GitHub repos for things like Helm, Kubernetes, Terraform, etc. because the custom YAML/JSON-esque templating setup misses vital features and we're having to re-learn the same stuff over and over again.
I think parenthesis-phobia is a red herring. The delimiter bytes in s-expressions denote structure, and most s-expression users are happy to render them as parentheses glyphs. Those who aren't are welcome to use one of the myriad preprocessors/renderers which display this structure in other ways, e.g.
https://srfi.schemers.org/srfi-119/srfi-119.html#Implementat... (converts back and forth to indentation)
https://srfi.schemers.org/srfi-110/srfi-110.html#reference-i... (converts back and forth to indentation)
https://srfi.schemers.org/srfi-49/srfi-49.html#Implementatio... (converts back and forth to indentation)
https://sourceforge.net/p/readable/code/ci/develop/tree/src/... (converts to indentation; an 'unsweeten.sscm' script converts the other way)
https://github.com/mjsottile/sfsexp/blob/master/src/sexp_vis... (converts to a graphviz tree diagram)
http://www.foldr.org/~michaelw/emacs/mwe-color-box.el (shows tree structure using nested boxes of different colours)
The fact that such tools aren't widely used shows that parentheses aren't a/the problem.
In contrast, the automake/autoconf support is actually a very complicated tower of helper scripts, override hooks, etc. which is built up on top of the system's built in support for running bash scripts (actually it runs whatever we call `builder` with whatever we call `args`; `runCommand` sets the `builder` to be bash and the `args` to be a file containing our script).
This is documented at https://nixos.org/nix/manual/#chap-writing-nix-expressions
And "Portgroups" are effectively libraries for the packaging system, so that they can easily interface with GitHub, CMake, gobject_introspection, etc...
[1] https://github.com/macports/macports-ports
Check out a similar recipe here https://github.com/openembedded/openembedded-core/blob/maste...