this post was submitted on 15 Jul 2024
22 points (100.0% liked)

Programming

17402 readers
105 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Rules

  • Follow the programming.dev instance rules
  • Keep content related to programming in some way
  • If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities !webdev@programming.dev

founded 1 year ago
MODERATORS
snowe@programming.dev
Ategon@programming.dev
MaungaHikoi@lemmy.nz
22
Plugins and config file (programming.dev)
submitted 4 months ago by grumpydeveloper@programming.dev to c/programming@programming.dev
9 comments fedilink hide all child comments
 

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

you are viewing a single comment's thread
view the rest of the comments
[–] MajorHavoc@programming.dev 2 points 4 months ago* (last edited 4 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.