<drakonis>also nix is making strides towards improving itself <zimoun>drakonis: thanks for the pointer. Quoting: «The Nix language is honestly the worst thing about Nix package manager.» Ouch! <zimoun>ahah! You are enjoying the new Emacs support of emojis. ;-) <civodul>i suggested that someone "translate" it to Guix <civodul>(i find the Nix/Bash snippets intimidating) <zimoun>Especially the ’with-imported-modules’ and then ’#~(begin (use-modules …’ <zimoun>Last, the ’result’ symlink is also handy. <rekado>I agree. It seems to me that sometimes there isn’t quite enough syntactic sugar. <rekado>arguably in the GWL I went too far in some places <zimoun>Well, personally instead of “flakes”, I prefer the workflow: my own Makefile, then a manifest file containing what I need, then “guix time-machine -C channels.scm -- shell -m manifest.scm -C -- make” <rekado>but I’d sometimes like to have a syntax that’s more focused on the doing and less on the structure <zimoun>and if I would like to replace my own Makefile, GWL is better, IMHO. <zimoun>civodul: opam (OCaml package manager) seems adding swhid to their metadata. <civodul>zimoun: the commit ID (swh:rev) or the snapshot ID, as a substitute for a hash? <civodul>oh so they have their own swhid resolver? <rekado>kir0ul: I’m not sure I see how this differs from “guix shell” <rekado>or jupyter-guix, the guix kernel for jupyter, which is like a meta kernel <kir0ul>rekado: looks like the same thing as `guix-jupyter` indeed <drakonis>it is a fancy wrapper for exposing the kernels to jupyter <drakonis>it exists largely due to how nix encapsulates packages into closures <drakonis>it is a fancy abstraction that makes things harder <drakonis>guix foregoes this approach by simply patching the packages to have a specific location for looking dependencies instead of wrapping them with a shell script <drakonis>nix's approach inevitably adds complexity <drakonis>since almost everything has to be nested in layers of wrapping to work ***civodul` is now known as civodul
<civodul>i think it's just a Nix interface to build environments containing Jupyter plus a bunch of kernels <rekado>civodul: yes, so “guix shell” with extra steps? <civodul>rekado: yes, looks like pre-built manifests for "guix shell", so to speak <rekado>it seems awfully complicated and verbose, so I feel like I must be missing something obvious. <civodul>yeah, it's also unclear to me why there's so much stuff in there <rekado>(I don’t want to come across as snarky and/or jaded; I really often have a hard time understanding what other people had in mind when they built something.) <civodul>achieving mutual understanding is prolly the trickiest part in software :-) <rekado>I feel like failing to achieve understanding is the fuel that drives “innovation” in software. <rekado>“X is Y, but without all the bloat!” <drakonis>rekado, civodul: basically it is full of things because it is a really roundabout way to generate a shell script that combines the kernels into a single environment for reading, as opposed to simply including them in a globally readable environment <drakonis>it needs to be done that way because it doesnt live in nixpkgs <drakonis>so it has to assume that it has to be completely independent from nixpkgs's jupyter definitions <drakonis>it is a common trait among nix's additional repositories <drakonis>guix is substantially more elegant about this whole thing