add multiple presets

[fwdekker]

users can currently configure MOMMY_COMPLIMENTS and MOMMY_ENCOURAGEMENTS to change what mommy will say. users who want a stricter, tougher mommy can thus configure mommy to do so by themselves, but I anticipate there will be a few categories of behaviour that many users will want. so why not add those to the default presets?

so, add a variable MOMMY_PRESET, which determines which preset is applied:

• if the preset is unset (or unknown), the default (current) sentences are loaded, and then the user's configured templates optionally override that
• if a preset is set (and exists), these override the user's configured templates (but not the *_CUSTOM variables, of course), since it does not make much sense to set both MOMMY_COMPLIMENTS and MOMMY_ENCOURAGEMENTS (unless a user wants to override only one of them, and use the other from the preset?)

[fwdekker]

since v0.0.3 (2023-01-20), mommy has allowed changing the config file with -c, as in mommy -c ~/.local/config/mommy/alternative.sh. however, i think this isn't quite easy enough for users.

i think the best way to implement the feature above is to simply add a new option, -p for --profile or --preset or --personality, which takes a single word like --profile=evil and will then apply ~/.local/config/mommy/evil.sh on top of the standard config files that are already being loaded, including the global config and the default config.

question: do i want to support global profiles?

[ninetailedtori]

Global profiles would be pretty nice, especially if we provided templating to /usr/share/mommy/presets/<preset-name>.json or something. This then would allow users to symlink ones they want to work globally to say, /etc/mommy/presets/, or user-specific ones, .config/mommy/presets/

[fwdekker]

thanks for the reply, @ninetailedtori!

note that there's currently no plans to support anything advanced like json. at least for now, configs will remain simple sh scripts.

if i understand you correctly, your suggestion is to:

• put "builtin" presets that are part of the mommy distribution (thus written by me or other contributors) in /usr/share/mommy/presets/ (or whatever path is applicable to the user's distro),
• put globally available presets in /etc/mommy/presets/ (or whatever path is applicable to the user's distro), and to allow symlinks in this directory, so the superuser can choose to enable the builtin presets,
• put per-user custom presets in ~/.config/mommy/presets/,
  right?

i think the only question left to resolve is how to handle conflicts, when there's an active global preset with the same name as a user's own preset. two options: (1) replace: the user's config takes precedence, and the global config is ignored. (2) combine: the global config is loaded, and the user's config is then loaded on top.

do you have a preference for which route to take? i'm thinking option 1, just to reduce complexity.

[ninetailedtori]

i think the only question left to resolve is how to handle conflicts, when there's an active global preset with the same name as a user's own preset. two options: (1) replace: the user's config takes precedence, and the global config is ignored. (2) combine: the global config is loaded, and the user's config is then loaded on top.

do you have a preference for which route to take? i'm thinking option 1, just to reduce complexity.

I'd say, that in terms of precedence, we're decided on the free desktop spec of user loaded as top priority over local then global then default?

Next I'd say in terms of fetching config, it should be done per configuration value, and each queried in the same order we stated here: check for the first defined in: user, local, global then default, mostly considering that for things such as replacing dialogue, it's much better to replace with top config values rather than merge, because the user might want to remove certain ones or have only specific ones, really.
It is possible to add a new config value that asks the user if they'd like to merge, but it would I think be much faster in terms of code to simply state in our template config file on the dialogue config line that "if you want to set config, all config will be replaced with these values, so if you'd like to keep any from the default configs, please copy them in as well", sorta thing! C:

[fwdekker]

mommy's configuration loading is probably different from what you'd expect: config files are just executable scripts that mommy sources to determine environment variables. if you wanted to, you could make your config file run Doom!

so there's no "querying per configuration value", and that isn't possible without some serious overhaul, and serious overhead. on the plus side: merging configs is super easy! just run both config files and see which environment variables get set in the end :)

i think i'll just go with the same logic used for loading the regular config file, and apply that to the presets as well.

[ninetailedtori]

Is there any potential for a formal json or yaml config file system? I wouldn't mind helping out, it's all just shell right? But if we keep as just a shell file to set the environment, that'll work fine yeah, have the file with greatest precedence be the only one taken into consideration, I'd say. It would probably prevent the system from getting super duper bloated as well. But we just gotta make sure that there's no security risk in using a raw shell env file as config, I suppose? Gotta be careful for stuff like malicious injection.

[fwdekker]

i'm not specifically opposed to parsing json or yaml. however, the design requirements for mommy mean that there should not be any non-posix runtime dependencies (so no using jq or such), so any parser would have to be manually written (or taken from another project and then included into our source code, assuming that's allowed by their license), but it would also have to be terribly efficient, because mommy runs on every terminal line, and waiting 100ms for mommy to complete parsing a few difficult file is not ok. (currently, mommy takes ~15ms of usr time with my own config.)

as for precedence: i think for global config files, merging makes more sense. the use case i've encountered myself is that you want to set a global basis for all users (e.g. change mommy's name for herself to the name of your server), but still allow individual users to customise. also, i don't think the system would get bloated with merging, because the files are not actually physically being merged.

for profiles, i'm more inclined to agree that only the highest-priority file should be loaded.

as for cybersecurity, you're right, but note that the trust isn't much higher than for, say, ~/.bashrc. the global config files are in dirs managed by the package manager, and the user config files are in ~/.config, which typically have permissions 700, so cannot be written to by others anyway.