Hi Sergey, Sergey Trofimov <s...@sarg.org.ru> writes:
> Hi Guix, > > I'd like to raise concerns about Guix's current approach to software > configuration management. Configuration schemas are inherently public > interfaces > of software, valid only for specific package versions. Currently, Guix > separates > these interfaces from the software they originate from. We place > =define-configuration= forms directly within Guix's source code, which > presents > several drawbacks: > > - *Potential breakage upon package updates:* Updating a package version can > inadvertently break Guix services that rely on it. For example, a removed > run > argument could cause the application to error upon startup. > - *Duplication of documentation:* The documentation for these records often > duplicates information already provided with the software itself, leading to > redundancy and potential inconsistencies. > > An illustrative example is mpv, where each version can introduce changes to > dozens of configuration options and run arguments: > (see https://github.com/mpv-player/mpv/blob/master/DOCS/interface-changes.rst) I think mpv is a bit of an outlier in our collection of services; most are using stable interfaces that rarely ever change (I would have expected the mpv options wouldn't change on a whim every release too? it does?), and do not have such a massive amount of options. > Therefore, I propose the following: > > Define "binding" Guix packages that provide Scheme code encompassing: > - Configuration data structures (records, =define-configuration= forms, > alists, etc.). > - Serializers for converting these structures into the software's native > configuration format. > - Run arguments specifications, detailing available options and their > expected types. > - Procedures for generating run commands based on the specified configuration. > > So, for e.g. =mpv@0.40.0= we can define =mpv-guix-bindings@0.40.0= package > that > depends either on =mpv= or its source: > - in the build phase generate scheme files by parsing the source code or the > output of =mpv --list-options= > - in the =check= phase verify that no changes happened in the public > interfaces (e.g. checksum of the input data used to generate code) What would the Guix package bindings upstream be? Each would have their specific git URL? Or would they be owned by the Guix project? I guess the later, and the use of a package is a means to compute something in a controlled environment. Would we continue adding the documentation produced by configuration->documentation in our manual? That's useful. > Then in Guix: > - remove existing configurations and documentation > - import configurations from binding modules, e.g. =(use-config-bindings pkg)= > would add =pkg-guix-bindings= modules to =%load-path= > - use the bindings where necessary, e.g.: > > ; generate config > (pkg-serialize-config > (pkg-configuration > (option-foo? #t))) > > ; prepare run arguments > (make-forkexec-constructor > '(#$pkg > #$@(pkg-run-args > (pkg-options > (daemon? #t))) > #$(pkg-serialize-config cfg))) > > Thoughts? I think both schemes could happily coexist, with the later an option for really complex packages such as mpv. Otherwise it feels like it'd add complexity for not much. We have system tests to detect breakage after all. -- Thanks, Maxim
