[bagasme]

After I digged into related articles on the link, it seems like the holy grail to the config files dilemma is to just hard-code desired settings in the source code. However, it also means that users (especially using binary packages) are stuck with settings from the distro.

If you truly needs user-configurable setting, maybe TOML is for you.

[__blockcipher__]

> it seems like the holy grail to the config files dilemma is to just hard-code desired settings in the source code

That is…not remotely the holy grail. You’re really throwing out the baby with the bathwater on that one. User-configurable settings are important for many, many applications.

In the narrow case that you’re working on, say, a monorepo for closed-source code that only runs on your own servers, maybe in source code is fine provided there’s no host-level differences that would require a config file.

But for any other circumstance…yeah you need some type of configurability.

[amluto]

Even with a single company closed source monorepo, sometimes it’s useful to change settings without a restart and redeploy. And sometimes one runs more than one instance of the same code.

[atoav]

I wrote a "common-config" module for an internal python project, that works like this:

1. You hardcode settings in python using a multiline TOML string

2. Users may have multiple configs at the usual config folders

3. The configs override the hardcoded defaults wherever fields are present

4. Configs override each other in order of directories (when we are talking about xdg-directories) and within them in alphabetical order wherever fields are present

This allows you to have good defaults, override some fields at will and add something like 99-debug.toml that you can just rename to 99-debug.toml.invalid if you don't need it anymore. The module also provides an install/edit cli and functions for printing the final resulting config and which configs it read on the way to that final config. At some point I have to publish it.

If you need anything more than TOML because your use case is so crazy, then consider either writing a domain specific language or use a scripting language like lua, python, js, ...

[deepsun]

Why not both? You can write config-looking Kotlin code so that user won't even realize it's Kotlin. But type-safe and with auto-completion.

Something like

    server {
      port = 8080
      addr = "127.0.0.1"
      development = true
    }
    
    db {
      url = $DB_URL
      user = "app"
      password = include(".secrets/dbpass.txt")
    }

[Lutger]

Not sure if I would call hardcoded settings in the sourcecode configuration - they are just constants. The primary benefit of configuration is the ability of changing the behavior of software without having to rebuild, redeploy, redistribute or even restart. Either by the user or by the developer or sysadmin, depending on context.