Open pabera opened 6 months ago
I think it's a good idea.
Only suggestion for clarity: call the file with the non changing parameters constants.yaml
, base.yaml
or default.yaml
(or something else, you get the idea).
I think settings
sounds like the users should change something here.
I think those could also be moved to default settings:
playermpd:
status_file: ../../shared/settings/music_player_status.json
mpd_conf: ~/.config/mpd/mpd.conf
is it possible that some parameters of a section (e.g. playermpd
) are in the default file and some are the file, which could/should be changed?
Feature
I recommend introducing a
settings.yaml
file for constants that users (builders) don't need to modify. Currently, ourjukebox.yaml
combines both user-relevant settings and constants. One might wonder why these constants aren't simply coded into the software, but occasionally, even these constants need adjustments, such as during development.In our existing
jukebox.default.yaml
, there are many details that aren't relevant to the builder, and altering them could impair the system's functionality.My suggestion involves adopting an approach similar to Docker Compose yaml files, where
settings.yaml
serves as the base andjukebox.yaml
acts as an override.Benefits would be:
jukebox.yaml
creating less confusion for users/builders.Here are several sections that could be separated out (as the comments also advise against modifying).