Andrew Tropin schreef op do 20-01-2022 om 16:20 [+0300]: > [...] > > From what I understood from Liliana's and Maxime's replies: I'm not the > only one finding the original implementation to be more intuitive and > consistent with the rest of Guix API. Please, correct me if I'm wrong.
To be clear: * >> source \ >> /gnu/store/00fl96dj2aak4i1vqvdqzlhbmmskc7fx-blabla.sh How about defining a procedure (define (source-file file-like) (mixed-text-file "source " file-like)), the 'concatenated-file' described below, and giving an example or two in the manual on how to use it? (concatenated-file "" (source-file (local-file "some-bash-functions.sh")) (mixed-text-file "" (file-append coreutils "/bin/echo") "hello Guix Home!) "\n" "invoke-some-function" "argument")) * I don't like 'slurp-file-gexp' (what are G-exps doing there, and what's slurping?). A better name would improve things though. Also, we already have 'mixed-text-file', so maybe we can create an ‘concatenated-file'? (appended-file name (plain-file "" "foo") (local-file "bar")) --> foo <contents of the file "bar"> A slight downside is that the plain-file needs to be given a name, in this case "", as you have noted for 'mixed-text-file', but that can be avoided to a degree by giving it "" as name. * IIUC, the reason why 'slurp-file-gexp' or the like was necessary, was because the implementation doesn't use records for configuration, but rather some mixture of S-exps and ‘copy this and that file is the serialisation here and there’. I would prefer not using S-exps like (home-service barfoo-service-type (barfoo-configuration (config `((this-option "that") (foo (bar z) (foobar (include ,(local-file ...))))))) and instead write these 'this-option', 'foo', 'bar' and 'foobar' in records, such that there's to some degree a type system and some discoverability. Yes, if there's a lot of options that can be configured, then initially Guix won't support all, but it should be easy to patch Guix to support more options on an as-needed basis. There can also be an 'extra-content' escape hatch. For software that doesn't support inclusion directives in configuration, we could: 1. patch upstream to support it (it's free software and it's potentially useful outside Guix, so why not?) 2. or do something like 'concatenated-file' with a preference for (1). As such, I'm not exactly agreeing, since there appear to be better options than 'slurp-file-gexp'. Renaming 'slurp-file-gexp' to something more descriptive would help, but there's more that could be done. Greetings, Maxime.
signature.asc
Description: This is a digitally signed message part