Hi,

I’m asking for opinions and preferences.

There is no right or wrong.

Scenario:

I have a tool (server component, api only, no gui) that has a config file and no per-user adjustable things. The admin can change things, of course.

Now the tool gets plugins, where to configure them?

  1. All in one config file with plugins having a section for their things,
  2. plugins get their own config file.
  3. the main config points to a storage (database) with config options for everything, a kind of variant of 1.
  4. something else/better

Hoping for a civil discussion ;)

Cheers

Grumpy

  • @[email protected]
    2•5 months ago

    Heh. Those of us with experience with these approaches know that there are plenty of wrong answers here, at least. The vote counts seem to be doing a pretty good job for anyone who wants a hint…

    Annecdotaly, I just pushed a costly release to correct problems caused by my naive past use of approach 1.

    Edit: a good rule of thumb for civil discussion is to use “I / me” statements, so:.

    1. I just had the all one file approach cause me a bunch of pain.
    2. I appreciate this approach where I find it. One config file per separately maintained code base is great.
    3. I actually do use a database to configure most of my network. I push my configuration decisions from my own database, into flat config files, with Ansible. Having the end product require another database complicates my efforts significantly. It’s not too bad if the product provides a command line option for each config change.
    4. I appreciate products that configure everything in one flat file per develeoper/maintainer, which is essentially option 2. This allows me to solve advanced use cases with my own configuration database, Ansible orchestration, and Jinja config file templates.