IRC channel logs


back to list of logs

<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!
<civodul>sunny Friday! 😎
<zimoun>ahah! You are enjoying the new Emacs support of emojis. ;-)
<civodul>see? :-)
<civodul>speaking of which, not sure if you saw that:
<civodul>i suggested that someone "translate" it to Guix
<civodul>(i find the Nix/Bash snippets intimidating)
<zimoun>well, “src = self” is handy.
<zimoun>and yes the snippet of Bash string has pros/cons. But I am not convinced something that ’(invoke "foo" #+(file-append bar "/") "--start #$(number->string num) …)’ is easier.
<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?
<zimoun>swh:rev IIUC
<zimoun>they do:
<zimoun>mirrors: [ ... "
<civodul>oh so they have their own swhid resolver?
<zimoun>yes, it is what I understand from Section 4. (Sorry, it is in French)
<zimoun>have a nice week-end :-)
<kir0ul>Is there something similar to this but using Guix: ?
<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>it is almost like monads i guess
<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>kir0ul, rekado: i don't think is a "meta kernel" like guix-jupyter
<civodul>i think it's just a Nix interface to build environments containing Jupyter plus a bunch of kernels
<civodul>it doesn't let you annotate notebooks like
<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!”
<civodul>heh, true
<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> oh man.
<drakonis>guix is substantially more elegant about this whole thing