> 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.
I just tried --export-manifest, and it feels like the right approach. Good one. > 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). Interesting. I didn't even know about `guix import json' and `guix describe -f json'. > 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. I certainly agree with the sentiment. I am a proud and happy Schemer myself! 😄 But I wonder if small concessions, if done in a way that didn't excessively raise our maintenance burden, could help us reach a much wider audience. Also, even from an engineering point of view, imagine how much pressure on `guix pull' could be relieved if we didn't have to compile our huge package collection everytime. Most Emacs packages, and lots of python, R, and Julia packages already fit this bill. If we generalized our build systems even more, we may be able to make more and more packages purely declarative. That could be a big win.
