As Flatfire mentions, another issue can arise if plugins can modify the config. I assumed config to be read-only for the software, only editable by the admins, and never by the tools themselves.
As Flatfire mentions, another issue can arise if plugins can modify the config. I assumed config to be read-only for the software, only editable by the admins, and never by the tools themselves.
I’d try to share the config space as much as possible. Options 1 and 3 make sense then.
What feels “right” to me, when using NixOS and its module system, is that all config has the same shape, and is therefor easily moved to a different section, or to a section that is shared by a subset of plugins.
Con: It could lead to bad practices like strengthening dependencies between plugins (if they hard code to use a specific config option of another plugin).
Pro: But if you can discourage that, or use “deprecated pointers” to the new location of an option, the ease of moving shared config options to a more generic level can make it easier to maintain the total configuration. Developers of the separate plugins can build on what others have already done, and even synergize functionality (add a convenient integration if they see another option configured).
If some options are “secret”, though, and you don’t want those shared, they should either be in their own config (easier), or you’d need some access control on the configuration storage/file for each plugin (more work). Allowing a plugin to have a separate file for credentials, for instance, could be a good choice.
That is an interesting source. Thanks for the link!
I will never not read LTT as Lews Therin first, of whom, as a lover of both FOSS and EotW, I definitely prefer being reminded.
E: my brain forgot that the series is called WoT. EotW is just the first book, indeed. But I’m rambling very much off topic here.
I guess it is a matter of how “fluent” you are in the language. With some foreign languages, e.g. when I started learning a bit of Japanese, I could recognize some kanji, understand some bastc sentences, but still had no idea what it would sound like. Maybe it’s similar to that. We get good at recognizing patterns and interpret them just enough to accomplish what we need, and if we haven’t had any use for “knowing exactly what it sounds like” (maybe just enough to recognize we are missing some notes while playing), we save the energy needed to learn more.
But a conductor would definitely need to know what it should sound like (or how they would want the orchestra to make it sound), so it is part of the interpretation of the pattern.
Same for lords patrician and other intra-audiophiles.
I do my time tracking in org-mode, and export it to JIRA once a day or so. It is quite a specific/tailored setup, written in a mix of elisp and, well, org-mode (specific names and tags are used to configure some settings), but I’d love to look at this tool to see if I can extend my workflow by using it for the “massaging into a nicer shape” part. I might end up writing some extensions for either side (org-mode input format and JIRA REST calls output format).
My current tooling quantizes everything by rounding start and end times to the nearest full 15 minutes, and starting a new task at the end time of the previous one when clocking in, so that my team lead does not have to report so many fractions of hours to higher layers.