Hello! Ricardo Wurmus <[email protected]> skribis:
> Ludovic Courtès <[email protected]> writes: > >> Ricardo Wurmus <[email protected]> skribis: > >>> Here’s an idea, which might be bad: how about adding a feature to load >>> and merge a directory tree of configuration files as they are? For >>> example, if I had a directory “/etc/guix/system/udev/rules.d” then all >>> files therein would automatically be considered part of the system >>> configuration, maybe after adding “/etc/guix/system” as a prefix path to >>> some new field in the “operating-system” declaration. >>> >>> I have a feeling that this will be considered a bad idea, but it also >>> seems to me that it would make the configuration of some parts of the >>> system easier than embedding file contents as strings in variables in >>> “/etc/config.scm” and modifying services manually. [...] > These files are not loaded at system runtime but upon running “guix > system reconfigure”. Their contents *at that time* would be embedded in > the configuration. Their state *at runtime* would not matter (just like > the contents of “config.scm” don’t matter at runtime). > > The files would become part of the configuration in the store. Changing > them would always require the additional step of reconfiguring the > system. OK, I had misunderstood your suggestion. It doesn’t have the drawbacks I mentioned. However, I don’t like the idea of having special directories that are automatically scanned. In my mind, it’s a problem similar to “macro hygiene”: we should not scan files whose name does not appear in config.scm. >> However, what we can do is improve the interface. Things that come to >> mind: >> >> 1. Change or remove the ‘udev-rule’ procedure; we should be using >> file-like objects instead, so one could store them alongside >> config.scm and write: >> >> (local-file "./my-udev-rule") > > Is this really so different from the bad idea I proposed? As soon as we > load files outside of “config.scm” users would need to copy more than > just the GuixSD config file to duplicate the system state on another > machine. In this example we would need both “config.scm” and > “my-udev-rule” in the same directory. It’s similar to your idea, except that the file is explicitly named in the <operating-system> object. If that helps, we could also allow users to specify a directory containing several rules, instead of just a single rule: (local-file "./my-udev-rule-directory") >> 2. Add a ‘extra-udev-rule’ procedure that you could use like this: >> >> (operating-system >> ;; … >> (services (extra-udev-rule (local-file "./my-udev-rule")) >> …)) >> >> thus avoiding the verbose ‘modify-services’ stanza. >> >> 3. (Instead of #2) Introduce a ‘udev-rules’ field in >> ‘operating-system’, just like we do for firmware. >> >> WDYT? > > I don’t know. Although this would simplify configuration I don’t really > like either of them for somewhat conflicting reasons. #3 gives special > treatment to udev rules (“What about Xorg config snippets?”), and with > #2 it seems like an unnecessary implementation detail that this > “extra-udev-rule” procedure is inside of the “services” field (“How come > this is a service?”). > > I also feel that we should avoid adding “special” syntax. Actually, I > really like how generic this whole “modify-services” business is. It’s > just a little too verbose to be user-friendly, in my opinion. I sympathize with that. In fact, <operating-system> translates to a <service> graph. The whole <operating-system> thing is just “syntax.” I would like to have a more formal way to describe this translation. I think this would allow us to fearlessly add or remove fields to <operating-system>. But I don’t know how to achieve it. In the meantime, we should still address the usability issue that you raised, which is why I made these suggestions. Thoughts? Thank you, Ludo’.
