Hello! Arun Isaac <[email protected]> skribis:
> I spoke about Guix at STEP-UP RSLondon 2026, a conference for research > software engineers (RSEs) primarily based at UK universities. Abstract here: > https://step-up.ac.uk/events/step-up-2026/abstracts/#software4 My > thinking was to advocate for Guix in the primarily conda+pip dominated > world of the RSE. I got some feedback that I'd like to share. Nice! I agree that editing Scheme has always been a high barrier. Jessica Talon’s talk at FOSDEM on this topic was spot-on. Regarding providing a command-line interface to our declarative configs, we made first steps in this direction: • By having the Guix System installer code generate an initial system config. (This could be extended for further editing.) • By adding ‘--export-manifest’ to ‘guix shell’ and ‘guix package’, and ‘-f channels’ to ‘guix describe’. For manifests, in all the tutorials we’ve given, ‘guix shell --export-manifest’ works well: you can do lots of things, including package transformations, without knowing Scheme. And I prefer this over ‘guix manifest add’ because the command itself is declarative: it’s stateless. The idea of a ‘guix channel’ command to add/remove/pin/unpin channels in a channel file has been on the table for a while. It’d be imperative, but still I think it’d be an improvement over the status quo. As for the syntax, I think going with toml, YAML, JSON or any other syntax du jour is not convincing to me. One reason is that this has already been attempted: with ‘guix import json’ (something nobody used), with ‘guix describe -f json’ (ditto), and with the use of WISP in GWL that didn’t have the desired effect (part of the problem has to do with WISP itself, but still). When discussing this, we should not underestimate the importance of consistency for newcomers. Knowing that everything at the end of the day is that Scheme thing you learned is quite valuable—that’s also the kind of feedback I got over the years. Thanks, Ludo’.
